I have a private derivation that uses an archive provided with requireFile and extracts a subset of it. Only the subset is needed at run time.
When I run garbage collection, the extracted files stay in the store but the original archive doesn’t, which can be an annoyance when I rebuild.
I don’t want to do something that prevents all build inputs of any type for any derivation from being GC’d globally. I also don’t want to do something that would add the original archive to the closure of the final package, as I don’t need to copy it around to destination machines when I deploy the package. But I would like to keep the archive in the store so that I don’t need to keep periodically adding it, and it would be nice if such archives were kept for as long as any derivation that used them at build time is kept.
Is there a way to do this that isn’t, say, manually maintaining symlinks to the archive’s store path to gcroots?
How do you manage the retention of deployable output? Maybe create a trivial multiple-output wrapper with two outputs being a symlink to the deployable, and a symlink to the source archive?
NixOps creates profile links for my machine configurations, which is how my deployable output is retained. (I set network.enableRollback = true in my NixOps configuration, which according to the comment I wrote above it is what makes this happen.)
So I guess I could create the derivation in a file accessible to both my desktop configuration (or my home-manager config) and my NixOps machine configurations, depend on just the binary output in the latter, and add a dependency to the source output in the former. It’s not elegant but it’d work.
Any chance there’s some other way to do it?
Well, in the layout you describe you could maybe just add the source file to the dependencies of your home-manager configuration.
I don’t think Nix supports some kind of fine-grained GC control that would be sufficient to achieve the goal directly.
1 Like