Nix Features: Atomic Upgrades, Rollbacks, Garbage Collection, and Functional Package Language

previously, the package won’t be built or downloaded a second time. At the same time, it is not possible for one user to inject a Trojan horse into a package that might be used by another user. ## Atomic upgrades and rollbacks Since package management operations never overwrite packages in the Nix store but just add new versions in different paths, they are _atomic_. So during a package upgrade, there is no time window in which the package has some files from the old version and some files from the new version — which would be bad because a program might well crash if it’s started during that period. And since packages aren’t overwritten, the old versions are still there after an upgrade. This means that you can _roll back_ to the old version: ```console $ nix-env --upgrade --attr nixpkgs.some-package $ nix-env --rollback ``` ## Garbage collection When you uninstall a package like this… ```console $ nix-env --uninstall firefox ``` the package isn’t deleted from the system right away (after all, you might want to do a rollback, or it might be in the profiles of other users). Instead, unused packages can be deleted safely by running the _garbage collector_: ```console $ nix-collect-garbage ``` This deletes all packages that aren’t in use by any user profile or by a currently running program. ## Functional package language Packages are built from _Nix expressions_, which is a simple functional language. A Nix expression describes everything that goes into a package build task (a “derivation”): other packages, sources, the build script, environment variables for the build script, etc. Nix tries very hard to ensure that Nix expressions are _deterministic_: building a Nix expression twice should yield the same result. Because it’s a functional language, it’s easy to support building variants of a package: turn the Nix expression into a function and call it any number of times with the appropriate arguments. Due to the hashing scheme, variants don’t conflict with each other in the Nix store. ## Transparent source/binary deployment Nix expressions generally describe how to build a package from source, so an installation action like ```console $ nix-env --install --attr nixpkgs.firefox ``` _could_ cause quite a bit of build activity, as not only Firefox but also all its dependencies (all the way up to the C library and the compiler) would have to be built, at least if they are not already in the

Nix supports atomic upgrades and rollbacks because package management operations add new versions without overwriting old ones. The garbage collector removes unused packages, and Nix expressions, a functional language, define how packages are built. Nix aims for deterministic builds and easy support for package variants. Nix also offers transparent source/binary deployment.