Fix `lorri direnv` triggering an unconditional rebuild every time it is run.
After fixing up the build loop people suddenly started noticing that
lorri was evaluating every time something ran `lorri direnv`, which
could potentially be every time the user switched between buffers in
the editor.
This is not the intended behaviour, since we should run an
unconditional build only the first time the project is added to the
watcher, and after rely on the watcher to notify us of any file
changes (or the user running `lorri internal ping` to force a
rebuild).
We forked lorri to nix-community, so this release also moves us over
to the new official repository.
Release notes:
Fix the build loop.
Previously, any change (for example a direnv ping or a change in the
nix files) would add a new build invocation to the queue, and the
builds would all be done one after the other.
However, a new build will always use the newest state of the files
anyway, so the CPU time spent on all the other builds will be
wasted (and hog your processor).
Now lorri will only
finish the current build (if running)
schedule at maximum one additional build if requested
This should improve the resource use drastically in some situations.
---
Make lorri daemon exit with exit code 0 instead of 130/143 on
SIGINT or SIGTERM.
---
Add lorri self-upgrade branch sub-subcommand.
This enables us to point users to a branch name, in order to test out
fixes from repository branches.
Patch release which adds a manpage.
Adding a `man` and a `doc` output, and copying the files to the
corresponding directories.
The `overrideAttrs` is necessary because `buildRustPackage` does not
allow adding outputs.
Changes the default fetcher in the Rust Platform to be the newer
`fetchCargoTarball`, and changes every application using the current default to
instead opt out.
This commit does not change any hashes or cause any rebuilds. Once integrated,
we will start deleting the opt-outs and recomputing hashes.
See #79975 for details.
In 87a19e9048 I merged staging-next into master using the GitHub gui as intended.
In ac241fb7a5 I merged master into staging-next for the next staging cycle, however, I accidentally pushed it to master.
Thinking this may cause trouble, I reverted it in 0be87c7979. This was however wrong, as it "removed" master.
This reverts commit 0be87c7979.
I merged master into staging-next but accidentally pushed it to master.
This should get us back to 87a19e9048.
This reverts commit ac241fb7a5, reversing
changes made to 76a439239e.
