Currently, lorri may regenerate the shell_gc_root link to the project
environments store path, even if that store path has not changed.
With this commit, lorri will now check if the current and previous
store paths are identical and, if so, avoid regenerating the symlink.
This is especially interesting as lorri instructs direnv to watch the
shell_gc_root symlink, previously causing direnv to be constantly
reinvoked for some projects.
If merged, this should also fix issue #387.
Closes #387.
Overview
I simply tried implementing the most obvious solution with guidance from #387. I have tested these by running the modified binary on my personal machine and with my personal projects.
Also, I am not sure if this should be classified as a feature or a fix.
Checklist
[ ] Updated the documentation (code documentation, command help, ...)
[x] Tested the change (unit or integration tests)
[ ] Amended the changelog in release.nix (see release.nix for instructions)
Whoops, it seems like those CI errors are out of my control...
Still, I can confirm that the ci script finishes with a exit status of zero on my machine.
Currently, lorri may regenerate the shell_gc_root link to the project environments store path, even if that store path has not changed. With this commit, lorri will now check if the current and previous store paths are identical and, if so, avoid regenerating the symlink.
This is especially interesting as lorri instructs direnv to watch the shell_gc_root symlink, previously causing direnv to be constantly reinvoked for some projects.
If merged, this should also fix issue #387.
Closes #387.
Overview
I simply tried implementing the most obvious solution with guidance from #387. I have tested these by running the modified binary on my personal machine and with my personal projects.
Also, I am not sure if this should be classified as a feature or a fix.
Checklist
release.nix
(seerelease.nix
for instructions)