Using Nix [draft]
This post aims to be a collection of useful tips & tricks that I've learnt over the years of using Nix & NixOS.
What is Nix*?
The Nix ecosystem has a lot of overloaded terms:
- Nix the language,
- Nix the package manager,
- NixOS the operating system,
- Nixpkgs, the official repository of Nix packages
How do these relate to each other?
- The Nix package manager uses the Nix language to define packages and interact with Nixpkgs.
- The NixOS operating system uses the Nix language and the Nix package manager to define an immutable operating system.
- Nixpkgs is a repository of Nix packages and software modules: build definitions of software and software services, written in the Nix language.
Advice on using Nix
You don't have to understand everything
2 years in, I still don't understand every detail of how Nix or NixOS work. My experience is somewhat like being an expat in a foreign country.
I have embraced the country fully and live there full-time, I can understand the spoken language somewhat well, I can understand the written language well, and I can make myself understood with some trouble.
In computer terms; I use Nix(OS) everywhere I can, I can read Nix code and understand what it does pretty well, and I can write my own Nix derivations by using existing references as starting points. But I can't read or write things fluently without using any reference materials.
Consult with references
- Keep a local copy of nixpkgs and use
grepto find existing examples for things you want to understand better, such as NixOS services or Nixpkgs helper functions.
- If you use NixOS, keep track of other people's system configurations to learn how they structure their environments.
- Consult the NixOS manual on how to install NixOS and on some explanations for various configuration settings.
- Read and follow along with the Nix Pills to understand how Nix derivations work and how to write them.
- Consult the Nix Reference Manual on anything related to how Nix works.
At the time of writing, this is still an experimental feature. However, it is the sane approach to Nix - I haven't even bothered learning how you would use Nix without flakes.
The corollary advice of using flakes is to avoid nix-env and nix-channel.
Use Home Manager
Home Manager is the Nix approach of maintaining user-level dotfiles.
You don't really need it if you only have one user, but still I find that it's been very pleasant to use even for single-user systems.
Direnv lets you automatically source your developer
environments when you
cd into them. Works beautifully in conjunction with
# Without flakes echo "use nix" >> .envrc && direnv allow # With flakes echo "use flake" >> .envrc && direnv allow
Using flakes without checking
lock.nix into Git
A controversial design choice of Nix flakes is that they require to be checked in with your source - or at least added (not necessarily commited).
This can make it painful to use when collaborating on projects that don't want to have these files checked in.
The solution I've found here is to use a parent directory with a dummy Git project.
dummy-parent/ ├── actual-project/ ├── .direnv/ ├── .envrc ├── flake.nix └── lock.nix
So when you
actual-project, you will activate the
developer environment specified in
aware of your Nix configuration.
Maintain multiple devices with one configuration
TODO! See my repository for now.