Reflections on NixOS

As a NixOS user I've certainly encountered some of these issues. While Nix and NixOS are really nice, the first thing I'd recommend to a new user would be to learn the Nix language, as it's pretty much a requirement for getting anything done.

I agree with the author that per-user configuration is a bit overkill for the common use-case of a single user machine, but you have to go out of your way to use it (via the "nix-env" command), so I think it's a bit of a non-issue. Since Nix can be used from any user's home directory anyway (this is often how it's used on non-NixOS systems), it's not necessary for Nix/NixOS to contain this per-user feature; however, by doing so they gain a huge space optimisation by re-using the same store. The same can be said for NixOS containers, which I don't use but I see why it's there.

As for making packages available at runtime, that's what the "propagatedBuildInputs" attribute is for. Sometimes Nix can actually automagically figure out runtime dependencies, since it looks through files as they're installed to see if they contain references to other store paths; if so, those paths are added to the runtime dependencies.

Perhaps that was a feature added after the article was written. It dates from January.

As a near-fanatic NixOS user (now!), I agree with both you and GP. The learning curve is brutal, so it took me a while to get started, but it's paid off several times over.

It's unfortunate that humans can't trust each other enough that saying "You'll like it after a few months" is good enough, but it's also an inevitable fact of life; for starters, the speaker might be mistaken. I don't think NixOS is for everyone, at least not yet.

And it's hard enough to run arbitrary software that, yes, you do need to learn the Nix language. In most cases it's as easy or easier to package the application for NixOS than it is to run it without packaging, which on the one hand is a benefit to the Nix ecosystem, but on the other hand can be a little annoying. There are workarounds...

But the workarounds require some unusual understanding to begin with.

I think one of NixOS' major flaws at the moment is documentation. There's the wiki, but it's both somewhat outdated and very much not comprehensive. As for Nix, it's been best explained in a series of blog posts, and as good as the Nix Pills series is, you have to find it before you can read it. It's also somewhat short on HOWTOs.

Most people don't like to spend hours writing documentation, though.

The existence of NixOS, and work done on it, is a massive positive externality. Even if it doesn't catch on, it's going to inspire half a dozen clones in the next decade or two. Unfortunately I don't see a good way to get more effort put into it, especially the boring bits (such as documentation)...

I suppose this comment is my way of trying to change that.

Would you suggest the Nix Pills series now? I notice it's 2 years old.

No, that is not what `propagatedBuildInputs` is for. `propagatedBuildInputs` should be used very sparingly, in most cases wrappers are the better solution.

For example, consider if every package that contained bash scripts would put bash in `propagatedBuildInputs`. Then I could not use a different version of bash for my user environment than those packages I installed used!

Also, `propagatedBuildInputs` are not even propagated into the user environment, the attribute that does that is `propagatedUserEnvPkgs` (not sure if that name is fully correct), and it is very sparingly used within nixpkgs.