We currently eagerly invalidate the gcroots and old profile rc,
assuming that the devshell is in a usable state.
If this assumption does not hold,
we can invalidate a working state for a broken one.
Here we just delay calling _nix_clean_old_gcroots
until we know that we're in a usable state.
In the case that the flake is in an unusable state,
this simply reuses the newest working state.
This should address #412.
- Always create the nix-direnv-reload script
- Use 0/1 for booleans
- Avoid crashing when profile_rc does not exist
- Use better internal variable name for manual mode
- Make use_nix work
- Avoid unneccessary forks
- Fix shellcheck failures
- Update mtime on profile rc files to avoid confusion about if the files
are up to date
- Add instructions to README.md
Adding nix_direnv_manual_refresh to .envrc will avoid the automatic
update of the nix environment on changes and allow the user to issue a
command to update the nix environment explicitly.
Sometimes it takes a long time to rebuild the nix environment and it
happens in times. Switching branches in or rebasing can be painful since
nix will re-evaluate between nix file changes.
This blog post explains the problems with blocking the shell:
https://dev.to/allenap/some-direnv-best-practices-actually-just-one-4864
This is a first prototype, the UX can certainly be improved a bit.
The per-user gcroot path has changed in Nix 2.14, so this is broken with
that. Regardless, this is preferable since it decouples from the Nix
implementation.
These are linked to the paths removed in $layout_dir. Since the links
are thus broken, Nix will take care of removing these during GC. This
avoids depending on where Nix stores gcroots in this fn (but not
everywhere in nix-direnv…yet).
`read` fails if it encounters EOF before the delim, the `.version` file
does not always have a newline, so `read` fails in that case. If the
env has `set -e` then this will abort. So add a newline to the end
always. Doesn’t seem to matter if there is more than one.
after importing from the nix environment
we currently concatenate the new and old values of XDG_DATA_DIRS,
which means if the nix environment reused or recreated the old values
they are now present twice.
XDG_DATA_DIRS is specified to be a "set",
and some software (GNOME for example) assume that its entries are unique.
this change reconstructs XDG_DATA_DIRS
by looping over the new and old entries
and adding the new ones among them.
it normalizes the entries by removing trailing slashes
to make duplicate detection a bit easier.
