Depreciate the use of nix-env to install packages?

As far as I’m aware that indeed is a long-term vision Eelco has, i.e. spare people from dealing with the Nix language by presenting an imperative interface, and I think that is in general uncontroversial. But unless it‘s prioritized and mapped out how to get there it remains a wishlist item.

There have been many debates going on and I think, as a community, we still haven’t figured out what exactly we want to do first with our limited resources. I don’t remember where I’ve read it, but someone recently proposed first stabilizing and polishing what are already well-explored use cases, and letting third parties do the risky experiments with more sophisticated ideas. That would give space for commercial applications to thrive while freeing up resources to work on the plumbing that everyone can trust and rely on. It would also naturally signal which applications are popular enough to cater to by the core system.

For instance, I simply doubt that imperative package management is important enough for the average software developer to be worthwhile to make work nicely. A guiding question to say no to proposals could be: Do people quit using Nix because we still haven’t fixed this?

nix-env littering beginner documentation is a good candidate: people did quit Nix because they messed up their setup and could not debug themselves out.

4 Likes

Total newbie here. What does the -A flag do? The docs page has nothing on it… Should the -A flag always be used whenever nix-env -i is used??

The “installing packages by derivation name” paragraph on this page explains that quite well (among all the other issues with nix-env): https://stop-using-nix-env.privatevoid.net/

The docs talk about it as well.

Either way, short answer, yeah, you should basically always use it.

2 Likes