Factor out `StoreDirConfig`
This takes out a bunch of non-virtual methods which only depend on the store dir.
I didn't move the implementation to a store-dir-config.cc because they were already split in two locations (path.cc and store-api.cc), and also because, I must admit, it will cause me grief later with more merge conflicts.
More progress on #5729.
depends on #6258 depends on #6237
I'm not really in favor of splitting things just because we can... Is there a specific use case for splitting off StoreDirConfig? (E.g. is there a plausible scenario where we have a StoreDirConfig that isn't a Store?)
Yes there is, https://github.com/NixOS/nix/pull/6237 which depends on this. I could pass a whole store there, but that that is somewhat sketchy from a caching perspective. If I just pass StoreDirConfig, it is more clear that the cache key does have something to do with the store dir, but no other store information.
This was working in Clang, but not GCC, due to that bug @thufschmitt ran into when first making StoreConfig. Hopefully I can fix soon.
Actually it's a double free instead. #6258 came from my attempts debugging this over the weekend. I rebase this on top, but still no dice.
I built with clang and the double free went away. Ugh!
Yes there is, https://github.com/NixOS/nix/pull/6237 which depends on this.
That's a bit of a circular motivation, because I'm not sure what the reason for #6237 is...
Err the motivation of #6237 is simply to use StorePath where possible to demonstrate the invariant that the item in question is in fact a store path, as we have done many times before, e.g. your recent #6198.
Ah thanks, yeah that makes sense!
@edolstra Yay! I was hoping the core change just got lost in there. I flipped the dependencies around so now this depends on that:
- In #6237 We share
Storewith the eval cache a bit more, which is sketchy re purity lest we accidentally use the store for something other than printing and parsing, but I suppose fine for now as eval contexts already have a store. - This PR will limit the use of
Storein the eval cache, in addition to makingStoreDirConfig. I assume there are many more instances where we could similarly do the same. (We could even makeEvalStatejust have aStoreDirConfigwhich is downcasted for things like IFD, a la what we did withLogStoreandGcStore.)
If you are not yet convinced by this, but #6237 now sounds good, hopefully this new approach is an improvement.
Still not sure how to fix this, but in the most recent commit found a bunch of locations that can be made StoreDirConfig instead of Store.
:tada: All dependencies have been resolved !
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/2023-11-10-nix-team-meeting-minutes-102/35379/1
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/2023-11-27-nix-team-meeting-minutes-107/36112/1
Backport failed for 2.18-maintenance, because it was unable to cherry-pick the commit(s).
Please cherry-pick the changes locally and resolve any conflicts.
git fetch origin 2.18-maintenance
git worktree add -d .worktree/backport-6236-to-2.18-maintenance origin/2.18-maintenance
cd .worktree/backport-6236-to-2.18-maintenance
git switch --create backport-6236-to-2.18-maintenance
git cherry-pick -x e97ac09abeab44fa3d10eb539f0b3d51f8575798 dde1d863388617b3a63db808c125f274c86a3222
Successfully created backport PR for 2.19-maintenance:
- #9561
Backport failed for 2.18-maintenance, because it was unable to cherry-pick the commit(s).
Please cherry-pick the changes locally and resolve any conflicts.
git fetch origin 2.18-maintenance
git worktree add -d .worktree/backport-6236-to-2.18-maintenance origin/2.18-maintenance
cd .worktree/backport-6236-to-2.18-maintenance
git switch --create backport-6236-to-2.18-maintenance
git cherry-pick -x e97ac09abeab44fa3d10eb539f0b3d51f8575798 dde1d863388617b3a63db808c125f274c86a3222
Git push to origin failed for 2.19-maintenance with exitcode 1