I’m giving a Nix presentation at work, and I’d like to demonstrate how Nix solves some concrete problems. Nix’s use of content-addressable storage and how that allows it to install packages that have incompatible dependencies seems like a natural place to start.
We hear a lot about how Nix solves this sort of “dependency hell”, but I’m having a difficult time finding a concrete example. Can you think of a pair of packages that demonstrates this well?
We hear a lot about how Nix solves this sort of “dependency hell”, but I’m having a difficult time finding a concrete example. Can you think of a pair of packages that demonstrates this well?
I think looking through all-packages.nix for version overrides will provide some examples.
For example, LibreOffice Still is built with a different poppler version than LibreOffice Fresh and nobody cares because the build is just more predictable that way.
Asymptote wants GSL 1.x, and we just pass it to the build.
Postgres plugin plv8 prefers a specific V8…
And then there is the fact that if you want to test the update, you just do a normal installation of the updated version and run before/after side by side without thinking twice; even across glibc updates…
The “dependency hell” in my opinion is at the boundaries when one $lang package manager stops managing the dependencies. Usually because a C library is needed. Or when using multiple languages and now you need to install all the languages at the right versions to do development, typically in a big monorepo that contains multiple services.
GitHub - nix-community/todomvc-nix: Example on how to nixify a project [maintainer=@Rizary] is an example project that demonstrates the use of Nix as the sole build tool for both Haskell and Node.
It’s probably not a good example because it’s just a project of my own and it’s over-engineered (I used it to learn all about unikernels), but passe is written in OCaml, and has a number of different compile targets:
Mirage is a unikernel, so mirage-unix is basically compiling against the mirage API but still running on unix for testing, while the ukvm/xen backends are the real unikernels which run on a hypervisor.
Particular ways nix has helped:
Some of mirage-ukvm and mirage-unix’s dependencies are mutually exclusive, you cannot install them all at the same time. I assume that typically users would manage this by keeping separate opam switches for each backend (think python virtualenv, ruby bundler, etc). With nix, I can compile for a given backend and I have only the current backend’s packages available automatically, without any manual management. I could even compile for all backends at once if I liked (but I haven’t had the need).
There are native C dependencies (like gmp and zarith) which require patches to make them work in a mirage unikernel. This is done with specific gmp-mirage opam packages (so it’s not unique to nix), but it is a good example of the benefits of not just having one package called “gmp” on the system, being able to use a different variant for different targets.
passe’s build process depends on npm packages, opam packages and python packages. The nix integration is absolutely not flawless (I’ve had to debug the npm and opam stuff since it’s not as well tested), but without nix I’d have to resort to a handful of different stateful package managers.
My suspicion is there may not be many popular open source tools with the attributes you’re looking to demonstrate, because popular projects need to support non-nix builds, and so maintainers will put in the effort to fix these problems in other ways (checking in their own versions of dependencies, downloading forks of dependencies as part of their build step, etc) rather than letting nix be the only way of building a project.
I am using Nix to manage GNURadio environment complexity and as a test/build pipeline.