[siraben]

This is a good overview of NixOS however it's very limited and barely scratches the surface of what Nix can do. I consider it a complete replacement for the "reproducible environment" problem that some programming languages solve (e.g. Python's virtualenv, Haskell's cabal repl), among others.

A simple example of this is when I want to run a Python script from the internet, I can execute

  nix-shell --run "python3 foo.py" -p "python3.withPackages (ps: with ps; [ numpy ])"

and now I'm in a shell where numpy is avaliable to the Python 3 interpreter. Or I could test the Haskell QuickCheck library and run

  nix-shell --run "ghci" -p "haskellPackages.ghcWithPackages (ps: with ps; [ QuickCheck ])" 

See[0] for a way to run programs without even installing them by prefixing them with a comma, e.g. `, hello`. Or what about running any Linux ELF binary by automatically getting their shared dependencies at runtime[1]? Or generating bootable ISOs from your NixOS configuration[2], cross-compiling with little effort[3], and so on.

These problems have already been solved to varying degrees in other places, but Nix lets you unify them (think of the huge amounts of libraries downloaded by cargo, cabal, node and so on scattered amongst projects and your home folder, Nix stores everything in /nix/store/) into a single framework.

I'd like to also say that the Nixpkgs repository[4] is super easy to contribute to, just open a PR on GitHub as opposed to sending patches via mailing lists, which is checked via the CI. I'm not sure if there's something analogous on other package repositories but there's also a bot[5] that opens thousands of PRs updating and testing packages automatically.

[0] https://github.com/Shopify/comma

[1] https://github.com/Lassulus/nix-autobahn

[2] https://github.com/nix-community/nixos-generators

[3] https://matthewbauer.us/blog/beginners-guide-to-cross.html

[4] https://github.com/NixOS/nixpkgs/

[5] https://github.com/r-ryantm

[firethief]

Another way you can use nix-shell: with Nix, shell scripts can declare their dependencies. For a random example, I have a script that extracts chapter information from a DVD. Its shebang looks like this:

    #!/usr/bin/env nix-shell
    #!nix-shell -i /bin/sh -p ffmpeg_4 lsdvd python3

This is the equivalent of "#!/bin/sh", but with some package dependencies. Without nix, this script would implicitly require lsdvd to be available, increasing the complexity and fragility of system administration: if you scp the script to a different machine, the script is broken there until you install lsdvd. Even on one machine, you have to keep lsdvd installed (and remember what you have it for). Nix takes care of all that: when you run the nix-empowered script, it will make sure lsdvd is available in the script's environment. I keep an extremely minimal set of packages install system-wide (and nothing installed to my user environment), and declare dependencies in the places they're actually needed. I no longer think in terms of installed-or-not; everything is available.

[jaemoe]

Seems really useful, thanks for the links!

[StreamBright]

Do you do these sort of things often in production?

[siraben]

No, this is to illustrate that despite Nix being purely functional it doesn't necessarily mean you lose velocity when doing things interactively. In production I usually use Docker. Nix can generate Docker images though, so I'd like to try it out sometime.