This is something I personally need but I also suspect that this is a promising approach for expanding Nix’s impact and reaching more users. If Nix can become the “go to” method for installing X package in someone’s CI workflow they’ll come to discover Nix automatically. People are also going to be far more willing to try out some new package manager in CI before they install it on their personal machines.
I looked into this further, apparently the biggest culprit is that you get a top-level checkout of the nixpkgs repo. And that’s 190MB out of the 270MB for a base install.
glibc is 32MB
nixexprs is 15MB
everything else is under 10MB and seems necessary for nix to work correctly.
If we wanted to improve this, we would have to “trim some fat” from the repo.
It seems to me that the download will grow arbitrarily large as nixpkgs and nix gain in popularity. I wonder if some ideas from the Unison project (https://www.unisonweb.org/ and https://www.youtube.com/watch?v=gCWtkvDQ2ZI) might be worth considering as nix is inevitably forced to scale.
The gist of it is that code is content-addressed along with everything else. For nixpkgs this could mean that users only need to download the AST version of all-packages.nix to start and then lazily download the Nix expressions for packages that all-packages.nix points to as necessary. Because everything is content-addressed this means just-enough downloads for the user and a very easy storage/replication for hosting the nixpkgs data.
some package are being removed, but definitely not at the rate in which they are being added.
I think eventually many things will be transferred over to flakes, in which you can opt-in to different ecosystems. And maybe nixpkgs will be slimmed down in size
Yes I know. I was asking @rickynils since he’s one of the dev of the other one, and I was wondering if his has some nice features that the cachix one doesn’t have.
I’d really like to get to a point where we can have an official GitHub Action to install Nix, or better yet just get Nix into the VM images. That way we can avoid this headache of figuring out the differences between a bunch of unofficial options.
The main motivation behind this action is to install Nix as quickly as possible in your GitHub workflow. If that isn’t important, you should probably use the Install Nix action instead, which sets up Nix in multi-user mode (daemon mode) using the official Nix installer.
It’d be interesting to find out, if anyone knows someone, what criteria GH uses, here.
I think it’s also good to know who does the work and how it would be maintained. And game out a bit what would need to happen if they weren’t keeping up with it.
Some context on why I think these are important: I’m picking at an unofficial replacement for the community-maintained Travis-CI Nix support (aside: I could use a little help here on well-defined small tasks–message if interested), which should be a stepping stone to asking Travis-CI to remove the semi-official support (and hoping they comply, and hoping the deprecation is smooth…). I’m doing this because the update process is so clunky that no one really seems to want to deal with it, but I think it’s a community-/dev-relations problem to just let the semi-official support rot (and it does, unless your project pins Nixpkgs).
Having Nix in the images would be great, as long as it’s going to keep working. If we have serious questions about that, though, there are advantages to having some form of ownership.
I don’t see it as bad, yet, but I am a little worried about ending up with too many CI flows with too much feature drift between them. Features are great, and experimenting to find improvements is also great, but choices also make it harder to onboard people, and feature drift also increases the switching costs.
s to spare!