-
-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use nix-store --add-root instead of hard-coding gcroot path (fix for Nix 2.14+) #311
Conversation
55f3ec7
to
d8b6332
Compare
I'm quite confused as to why this is failing. However, the main question I have right now (and I am surprised that it's taken me this long to realize this) is: Why aren't we using |
I also don’t understand the failure. I did a few runs with I did end up temp. removing the
|
Is it really orthogonal? it creates the roots without us having to worry about exactly where the gcroot got created. Regarding removal: couldnt we just remove the created files inside $LAYOUT_DIR, which would cause the symlink to dangle and then qualify that root for collection? I tried to figure this out but couldnt get nix 2.14 no matter how I tried. The latest i got was 2.13.3 with latest nixpkgs-unstable and the nixUnstable package... |
I mean that I don’t think it will fix the failure currently on this branch, it’s certainly relevant to the problem this branch is trying to solve. Yes, I believe you’re correct, there’s no need to micromanage all the references during removal so we don’t have to care. |
d8b6332
to
d9a7c33
Compare
I’ve force-pushed an alternative impl based on your suggestions—definitely much nicer! However the tests are still failing and it’s not clear to me yet why it doesn’t think it can use the cache anymore, but I need to big a bit more through the trace. |
I have pinned the ci to nix 2.13 for now. You may want to unpin in this PR for testing: #312 |
Had a play around with this yesterday (using the podman image released as part of the nix-unstable-installer releases) and the problem is either in gcroot creation or gcroot persistence after garbage collection. The first pass seems to work well enough (after first GC, but pre second GC in the tests) but post-GC, we consistently enter the "cache invalid" portion of the branch logic. I modified direnv to print out WHY we were entering that part of the branch and it is because |
d9a7c33
to
ced1c05
Compare
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).
ced1c05
to
bd37b1a
Compare
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.
bd37b1a
to
49de6ab
Compare
Alright, this is working now. It ended up being quite simple, but, IMO, the API of I’ve rebased off master and amended in the change, which is just: diff --git a/direnvrc b/direnvrc
index 539168e..a447268 100644
--- a/direnvrc
+++ b/direnvrc
@@ -132,7 +132,7 @@ _nix_add_gcroot() {
local symlink=$2
ln -fsn "$storepath" "$symlink"
- nix-store --realise --add-root "$symlink"
+ nix-store --realise "$storepath" --add-root "$symlink" >/dev/null
}
_nix_clean_old_gcroots() { |
I didn’t want to unpin Nix in CI in this PR (probably pinning to something is useful to prevent unexpected change, and perhaps CI should run against multiple versions). I did a CI run on Nix 2.15 that passed. |
I'm happy to merge this JUST for the simplification in root creation alone, but the fact that this makes it work moving forward to nix 2.14+ is awesome! I'm actually inclined to unpin the Nix runner here as I want it to fail on unstable Nix versions so that we notice breakage. @Mic92 do you have thoughts on this? I'll go ahead and revert the pin if you don't have issue. Going to go ahead and merge this. Thank you for the contribution! |
@bbenne10 please do so. |
Do so by no longer hard-coding gcroot paths, and defer to Nix to manage things.
NixOS/nix#5226