Nix

nix.dev, Nix One Pager & Nix Book are great places to start learning/using Nix. How to learn Nix series is great too.

Looking into using Nix Quick Install Action in my projects. devshell, statix deploy-rs are neat.

I used Nix time article to install Nix on my mac.

Evolution of Nix is a nice historical talk on Nix.

Notes

Nix never uses host dependencies, it always builds with exactly precise dependencies every time, and will always refer to them from then on.
Nix lets you roll back changes atomically.
nix-shell lets you make build environments that are totally reproducible across machines, and don’t interfere with each other. You can freely mix any number of libraries of versions or software on the same machine and they don’t conflict.
With Ubuntu, every time you want to fix something with your car, you roll it into the garage, pop open the hood and get to work. It's intensive labour, results will vary, and undoing a change can be difficult.
- With NixOS, it's like 3D printing a new car every time. You'll design a model, press a button, and the car gets built from scratch. If you don't like it, tweak the design a bit, and print a new car. If the new car breaks, just go back to the previous known-good one, which is already in your garage. You can even take the design documents to your friend and generate an exactly identical model.
sudo command sets the wrong $HOME, have to use sudo -i for nix commands that need sudo.
Nix is Turing complete language used for configuration and building packages.
Can use nox, nix search, nix-repl, nixOS packages to search for packages.
Think of Nix (the language) as an expression-based programming language where every program evaluates to a single (possibly complex) value; that resulting value is what is used as eg. the configuration of your system or a package, but it means that you can generate that value based on arbitrary logic and abstractions like you would with a regular programming language.
As for domain-specific package managers, It Depends; it's possible with varying degrees of hackiness (and I definitely use eg. npm for development), but for a 'real' deployment - whether as a service on a server or as a local application - you'd want to convert your project's metadata to a Nix expression and let Nix handle the dependency management.
Overlay adds/overrides something in the global package set.
In general, you should only install things with nix, and not use any other package managers.
The main idea of the Nix approach is to store software components in isolation from each other in a central component store, under path names that contain cryptographic hashes of all inputs involved in building the component, such as /nix/store/rwmfbhb2znwp...-ﬁrefox1.0.4.
Don't install libraries with Nix.
Derivations are variables + build script.
Docs are in .xml files in /docs
To build derivation in nixpkgs, at root of nixpkgs, run nix build -f . <pkg-name> (ie nix build -f . wifi-password)
To find out the SHA256, run nix-prefetch-url -A <pkg-name>.src (ie nix-prefetch-url -A wifi-password.src). nix-prefetch-url works with GitHub. This gives you the SHA256 you can copy.
I think Nix's approach is the right way to build container images--build the image layers declaratively, reproducibly, incrementally (no, Dockerfile builds aren't incremental because dependency trees aren't linear), and without a container runtime dependency.
Nix doesn't solve dependency resolution problems. Only pinning. There's ground to break there. Dependency management not being part of flakes is my biggest gripe with it. It would be our chance to be the once size fits all solution but we failed to deliver.
There's a lot of unexplored potential of Nix in granular build systems and displacing systems like Bazel. If applied correctly, it lets smaller organisations get much of the benefit of Google-style monorepos but without as much maintenance overhead.
Nix doesn't have an issue with metadata revisions: they're just another explicitly declared input to the build so they don't violate purity.
Nix has an incredibly steep learning curve atm, but has completely eliminated entire classes of problems for me such as per-proj software deps and consistent environments, and has removed any fear of experimentation (since I can always rollback). Nothing else does this today.
Nixpkgs overlays are monoids, where pkgs.lib.composeExtensions is the associative binary operation and (: : { }) is the identity element.

Code

# Build nix package locally.

# cd into cloned https://github.com/NixOS/nixpkgs

# Build package from default.nix inside nixpkgs. Will put result as ./result if succeeds
# i.e. nix-build -A watchexec -> will build watchexec package
nix-build -A <package>

# Install the build and put it `~/.nix-profile/bin`
nix-env -i ./result

# Garbage collect
sudo nix-collect-garbage --delete-older-than 30d

Nix

Notes​

Code​

Links​

Notes

Code

Links