The other day I found out about the Nix package manager. It’s interesting because each version of package (called a derivation for some reason) is in an isolated directory, and the environment is built from symlinks and long PATH variables and the like. This gives some niceties like atomic upgrades, and the ability to reason about broken dependencies much more easily; the developers term it a purely functional package manager. You can also have multiple versions of a package installed and switch between versions using a “profiles” feature.
This got my brain working a little. In Nix, the packages are specified as a set of attributes and a shell script that together describe how to build the package from source. When installing, it first checks various places for a suitable binary version and if there isn’t one, it will download the source and build it. So Nix could give us beautiful support for testing and hacking on bits of GNOME. Imagine I decide to rewrite GtkTreeView, for whatever reason. I set up a new profile which uses Gtk+ from git, and keeps the source in my home directory somewhere. Nix can download binary versions of the latest GLib unstable, and any other deps not satisfied by the distro, so I don’t have to waste time building those. I’m not sure what Nix would do about the apps that depend on Gtk+; ideally you could tell it the ABI wasn’t changing so it would just run the same versions of apps but linked against the unstable Gtk+. This isn’t possible at the moment and would be hard to implement, I imagine. Right now Nix could install new versions of various apps, hopefully just the ones you specify to save duplicating your entire system. The point anyway is that now I can do some hacking and test my changes in my real environment straight away, all with no danger of breaking my actual system.
I know there are major obstacles to achieving this. Nix isn’t perfect – it uses wastes quite a bit of time and disk space, although there is a distro using it in the real-world. I wrote to their mailing list, and it seems like a lot of what I mention above is possible but isn’t really documented or used much at the moment. And of course it’s not like jhbuild doesn’t work well. Still, I kind of think this is a vision of the future. It would be awesome being able to pick and choose bits of your system to hack on and have it integrate perfectly.
Interestingly, nix would also be really useful for packaging MSYS. I mean the dependency problems there are so complex that the msysGIT people choose to ship an entirely separate environment.