Nix the package manager is for getting deep control and hard guarantees about your dependencies. NixOS uses Nix, but also gives you ways to 1) specify your system's configuration declaratively from the beginning* and 2) reliably get that configuration running on another machine without having to worry about, say, conflicts with existing dependencies.
Or at least that's the theory. In practice I'm mostly still trying to get my mouse to work. :-P
*As opposed to layering a declarative system over an imperative one, which I think is more or less what Chef, Docker, Ansible, et cetera are doing.
That means I'll have to rewrite all my (Arch) packages for Nix in order for that to work, right? How does it deal with install scripts (inside upstream packages that you have no control over) that install stuff imperatively?
if a package is "installed" in an environment (it could be global, user local or temporary), its files are sym-linked in the "original" position (e.g. /usr/bin/firefox etc etc)
Small nitpick, they aren't symlinked to their original position, but instead to a "profile" (global for instance is in /run/current-system/sw, your local profile is $HOME/.nix-profile).
This has several consequences. It means binaries distributed with the expectation of libraries being in their original position (e.g. /usr/lib/libc.so) don't work as is. It also means scripts depending on the presence of /usr/bin/bash are broken (which happen far too often).
I love NixOS, but that is one of the biggest annoyance I have with the system.
With packaged softwares, yeah it rocks and it's seamless.
The problem comes from anything that's not packaged. Things that exist outside the nixos ecosystem.
For instance, the Android SDK is a bit of pain in the neck to install via the nixpkgs : it's a mutable piece of software with pieces that auto-update themselves, made of lots of smaller packages that aren't bundled in the main package, etc...
However, the binaries google provide doesn't run properly on nixos by default because of the non-standard install (has to set LD_PRELOAD so it can find the libc).
Well the Android SDK is like the worst-packaged thing ever :). I thought that its nixpkgs package was one of the greatest efforts to salvage the situation---the XSLT to automatically convert it's xml metadata to nix expressions is super impressive.
I don't know if a mechical/automatic process is possible, but it works for haskell and python packages from Hackage and PyPI.
nix packages are not exactly packages, as in rpm or deb files, they are expressions in a functional language (think build recipes). there is a central repository of recipes on github:
https://github.com/NixOS/nixpkgs/tree/master/pkgs
Yeah we package a lot of stuff these days---more than our market share would lead one to guess. So yes feel free to file a PR for anything missing, but there's no need to port Arch packages en masse.
Or at least that's the theory. In practice I'm mostly still trying to get my mouse to work. :-P
*As opposed to layering a declarative system over an imperative one, which I think is more or less what Chef, Docker, Ansible, et cetera are doing.