2 ms·
One downside of Nix compared to, e.g. Make, is that it's quite heavy-weight; e.g. we can't just run it as a standalone binary. Despite this, it can still be us
by chriswarbo 5y ago
One downside of Nix compared to, e.g. Make, is that it's quite heavy-weight; e.g. we can't just run it as a standalone binary.
Despite this, it can still be used in small, gradual ways. Some nice starting points:
nix-shell as a #! interpreter, e.g.
#!/usr/bin/env nix-shell
#!nix-shell -i python3 -p gnuplot -p "python3.withPackages (p: [ p.numpy p.scipy ])"
import numpy as np
...
This is a standalone .py script (not a .nix file). When executed it will run nix-shell, which will set up a temporary environment whose PATH contains gnuplot and a python3 executable with numpy and scipy in its site-packages (the '-p' arguments). It will then run the script using the python3 command (the '-i' argument), as if the #! line had been '#!/path/to/that/particular/python3' all along. These dependencies will come from Nixpkgs by default, which is one of the largest and most up-to-date package repos in the world (see top-right of https://repology.org/repositories/graphs https://repology.org/repositories/graphs )
Another nice "baby step" is again to use nix-shell, but this time we write a .nix file defining all of the development tools we want to use, e.g.
with import <nixpkgs> {};
mkShell {
packages = [ gcc gnumake valgrind shellcheck emacs ];
}
If we call this file 'shell.nix', then running 'nix-shell' within that directory will start a shell with all those packages available in its PATH. This is useful when we don't want to install a bunch of tools system-wide (or, as we get more specific and explicit, it lets us use different versions of tools for each project).