There is a lot to Nix. We’re not going to get into it here. If you are interested, there is a lot of documentation to explore. For our purposes Nix is a tool that allows you to contribute to a project that uses a development ecosystem you are not invested in.
While there is some initial setup, you don’t need to become invested in Nix to benefit from this aspect of it.
A scenario: some application that you use has some annoying behavior that you seem to be the only person to run into. Thankfully, the application is Open Source™️, so you can download it, fix it, and send a patch to the author.
However, once you download it, you discover that it’s in a language you have
very little familiarity with, and you certainly have no idea how the build
tools, tests, etc. all work. Beyond that, the README assumes you are already a
$LANG developer, with most of the tooling pre-installed and only lists a
smattering of the actual dependencies you need. Not to mention that you don’t
want another set of developer tools that you won’t use infesting your computer.
Nix provides a wrapper that gives you a common way to work with disparate ecosystems. It ensures you get exactly the same versions of every dependency that is used by other developers, CI, etc. After you’ve finished and tested your changes to the project, the entire development environment can be cleaned up, leaving your system unchanged from before you made your contribution.
First, install Nix. This is the most painful part of the process.
Second, there are two different ways for a project to use Nix, you can identify which it is based on the files you find.
Flakes are the newer and recommended way of working with Nix. Unfortunately,
it’s still considered experimental, so you need to do some minor configuration
to enable it. Create a config.nix file (where?) containing
experimental-features = [ nix-command flakes ];At this point, you’re ready to try building the project before you make any changes, to make sure that what you’ve checked out actually works.
$ nix buildThis should do everything you need, depending on the language. Could be like
configure; make; make check for a C project or cabal new-build --enable-test
for a Haskell project, or any number of other sequences of commands that you
don’t have to bother to learn.
However, nix build can be very monolithic. Depending on the way the project is
set up, it can take a very long time every time you run it. This can be
frustrating in the middle of development. In this case, you can run nix develop and use more fine-grained commands to just redo the pieces you need.
… add more here …
Once you are done, there are two commands you should make sure to run before you push to make sure everything works.
nix flake check– this will run checks like linters, etc. to make sure the content of the project is up to snuffnix build– just like before we started, builds the project, runs the behavioral tests. This is likely very similar to what CI will do with your PR.
Projects with flake.nix often do provide these files for backward
compatibility, but flake.nix is much richer, so I recommend only following these instructions if there is no flake.nix.
nix-build
nix-shell
I’m still not going to talk about all the other things you can do with Nix, but you can take the ideas here a bit further.
