alt Hacker NewsAlthough that is true, it'll presumably be hard to use them all since some of them will trample each other's symlinks.
It doesn't really make that much sense, but I've always wanted a sort-of hybrid lazy Nix store. Rebuilding my NixOS machines take a long time since I like to have my preferred software configured and installed at the system level mostly, but there's some stuff that isn't so essential that it needs to block the upgrade. So I've thought about a hybrid solution where the packages would get built in the background and you could have some kind of magic FUSE system to block while the derivations are built or pulled from Hydra.
If you wanted to, you could combine this with the idea of installing every Nixpkgs package. It might even sort of make sense, as long as you ditch the "also work on them in the background" part... although it makes the surface area of your system absurd.
Replies
AppFS (my project) and CERN VMFS do this, if I understand you correctly.
>some kind of magic FUSE system to block while the derivations are built or pulled
Like OneDrive in Windows
i have a system level and a user config, so the system is always the basic stuff like emacs and chrome, while the user config will pull in things like vlc, evince, etc. plus it's not like you have to log out to rebuild, it just fills up your bandwidth.
Hey, I sorta did this. Lazy substitution, at least, not lazy build. Plus a bunch of tricks to speed up downloads.
https://github.com/dnr/styx/
Lazy build sounds tricky: you don't know the contents of the package before you build it, so you don't even know what to symlink into /run/current-system/sw. I guess you'd have to have some kind of wrapper. Maybe similar to comma.
I just solved that part by setting up CI for most of my system config (integrated with the above).