From here, add the above to systemPackages in /etc/nixos/configuration.nix. You can then remove
all packages from your profile with nix profile remove '.*'.
Tip: run nixos-rebuild switch before removing all packages from your profile.
Factoring out certain detailed knowledge to specialists reduces the intellectual complexity of a task, which is one of the things computer science is about.
— Grune, D., & Jacobs, C. J. H. (2008). Parsing Techniques. Monographs in Computer Science. doi:10.1007/978-0-387-68954-8
nix is good. It’s a lot of things, it can be hard to get everything that it’s about. But one thing that it is extremely good at it managing binary dependencies. One can think of it as a package manager like brew, apt, or pacman, except that one have unlimited number of minimal (or even mutually incompatible) environments whose definition can be easily shared with other developers (or just yourself, say, if you want to be able to quickly spin up an environment on another machine). It is also far more convenient than docker, as it runs natively as opposed to within a container, which can require setting up the network, often does not play well with your IDE, requires managing images, etc.
nix can also be used on CI/CD when you’re ready for it – meaning that you’ll have the same environment there as on your local box, more or less.
If you’ve used virtualenv for Python, you can think of nix as being just like it, except that it can manage higher-level binary dependencies like your language, your language’s package manager, etc. with ease.
To use nix as an environment manager for a given coding project, I suggest the following:
If you have used git for a little while and know how to rebase, you should probably enable the following:
git global config --global pull.rebase true
This means that if your branch looks like this:
origin: a-b-c-d-e-f-g
your branch: a-b-c---------x
and you want to merge in the version on origin, it will rebase your branch instead of creating a merge commit. Two of the things that I like most about rebasing on pull as opposed to having git create a merge commit are:
if you have merge conflicts, you can fix them up one-at-a-time as opposed to having to fix all merge conflicts as once
you don’t end up with merge commits in your git history