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 87a19e9048773d5a363679617406ad148d36c3b8 I merged staging-next into master using the GitHub gui as intended.
In ac241fb7a570d6cf81d229ad22a8889602639160 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 0be87c79797a5fa384fbc356c74ed54f9f7829ea. This was however wrong, as it "removed" master.
This reverts commit 0be87c79797a5fa384fbc356c74ed54f9f7829ea.
I merged master into staging-next but accidentally pushed it to master.
This should get us back to 87a19e9048773d5a363679617406ad148d36c3b8.
This reverts commit ac241fb7a570d6cf81d229ad22a8889602639160, reversing
changes made to 76a439239eb310d9ad76d998b34d5d3bc0e37acb.