[rgoulter]

That's kinda fair, but I think it's worth keeping an eye on.

Nix is really good at "programmatic environment for managing packages". Which is excellent for devops. There are advantages for developers, too.. but, developers can get away with quicker + dirtier solutions a lot of the time.

e.g. Maybe your project assumes a specific version of Ruby or whatever. Nix can solve this in a nice way, but you can use Ruby version manager (or the general asdf). Want to install Python packages, without conflicting? Nix can solve this in a nice way, but you can use virtualenv. Build a container image? etc.

An example of "practically useful, which Nix can do, others can't" I've seen is "just run the code from some repository". The non-Nix equivalent I've seen is `docker run <some image for a CLI tool>`. Nix allows the same UX, but without relying on containers. -- I think that's something everyone could benefit from.

I think the benefits for developers are definitely there; the main downside is that compared to those "quick + dirty" solutions, anything off the happy-path with Nix is quite difficult.

[panta82]

I can see how it would be a good system for ruby or python packages, or a docker replacement.

But it seems it isn't able to blindly mirror stuff from pip, for example? Or to just package any linux under the sun, like Docker can? You'd have to have a nix-specific version of every package you want to use.

And then, the first time you hit upon a package it doesn't have, you have to develop and maintain your own version of it (as far as I understand?). This sounds like a lot of work for someone who wants packages to just work, so they can focus on other things.

I remember using freebsd at some point. The annoyance of not being able to just grab a deb from random sites and install them far outweighted any benefits I got from a cleaner OS organization and some extra features. Nix feels the same way.

I am not saying nix is a bad idea or that it'd have no benefit. Just that, for non-enthusiasts and non-early adopters like myself, it's dead in the water until there is some major support behind it.

[rgoulter]

> Just that, for non-enthusiasts and non-early adopters like myself, it's dead in the water until there is some major support behind it.

Sure, this is pragmatic.

> But it seems it isn't able to blindly mirror stuff from pip, for example? Or to just package any linux under the sun, like Docker can? You'd have to have a nix-specific version of every package you want to use.

Building a DEB package with Nix is apparently possible, if quite awkward. https://nixos.wiki/wiki/Nixpkgs/Building_RPM_DEB_with_nixpkg...

The story looks a bit better for images. Packages can run appimages or snaps. https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-appimageTo... -- Which seems a decent compromise.

I think the effort of "I have to package this" varies from "automatable" to "PITA".

My experience has been that for writing package expressions for Python packages or Golang applications, it was more/less straightforward copy-pasting that required little Nix understanding. (The effort being: what are the sha256 sums, and what are the dependencies). -- I think to an extent this can even be done by "<lang>2nix".

An example of difficulty I've run into was trying to package a repo where I was unfamiliar with the language, and where build process assumed they could modify $HOME. I noticed that e.g. the anki package had to have a workaround anki-bin in order to get up-to-date versions because anki's build process changed.