There's overlap in the community/technology, but they are separate projects. Oftentimes people think that Guix is a fork of Nix, but this isn't so. Fun fact: Guix was started by a former NixOS developer.
Interestingly there are several threads on the nix mailing-list right now discussing how to do just this: implement a language-specific package manager, for a brand-new language, using nix. One guy is even using it to replace make.
Are there advantages in developing a new package manager today? There are many mature packaging systems (npm, Bower, Nix, OPAM, ...) which are not written in Go but could probably be adapted to support the Go ecosystem. Moreover, using an existing solution prevents the human cost of debating on "design choices".
Nix/Guix have been brought up a bunch of times in follow-ups. I was aware of Nix (though not Guix) before writing the piece, and I do need to check it out. But...
The primary requirement for a PDM is that developers will actually use it. If the interaction is much more complicated than the command diagrams I laid out towards the end of the general section, it's really just not gonna happen. Maybe someone could build a guix frontend that focuses in on just those things. I don't know. New territory for me.
My guess, though, is that SPMs and PDMs are really only superficially similar.
The important thing is that the underlying idea is rock solid, and the work of taming all the crapily packaged software out there is mostly done. So yes there is work to do but its already getting easier. Big todos:
- Proper CI. We need to not merge PRs until we know the merge commit builds. (Travis is wrong in this regard.)
- Sane CLI. Things change over a decade (cough git cough), but good news is were going to replace the whole damn thing 0-fucks given for backwards compat and make something sane even for those that don't appreciate/understand the underlying elegance.
- Support for institutional installations: A central build daemon + farm is a pretty lame say to synchronize things. Should make it so anybody can build stuff, and anybody can share binaries with those that trust them, and shared NSF store or equivalent for de-dup.
> Support for institutional installations: A central build daemon + farm is a pretty lame say to synchronize things. Should make it so anybody can build stuff, and anybody can share binaries with those that trust them, and shared NSF store or equivalent for de-dup.
At the research site where I work as a software person, we use a central guix-daemon managing a shared NFS store. Anyone can build stuff and manage their own software profiles from cluster nodes. Works very well for us and gets us a big step closer to reproducible science.
Sharing build artifacts also works with Guix. You can either export from and import items to the store or use "guix publish" to share items via HTTP.
The daemon runs as root (on one server that has write access to the shared store) to spawn build processes in chroots (work is underway to use user namespaces where possible). The builds themselves are performed as unprivileged build users. Users communicate with the daemon via RPCs.
Since every build is forced to its very own unique output directory (by prepending a hash of all the inputs), one user's build/installation does not affect other users.
SCNR.