I won’t defend the use of nix-env or nix profile, especially on NixOS, except to say that these are pretty essential tools on non-NixOS systems that allow users to migrate from other package managers.
On non-NixOS systems impure global installs are a huge draw for VMs and some CI. Which I’d argue is a legitimate use case for them. I can spin a reproducible worker for almost any distro without much effort. I don’t have to depend on something like home-manager, or nixos-darwin, and I don’t have to add any wonky homemade hooks to my .profile to get those boxes to have certain tools available.
But the real use case is: there’s a 0% chance of me convincing people at work to adopt Nix without a rough equivalent for apt install or brew install. For folks that don’t know much about Nix these allow them to use packages built by Nix without sending angry emails and rallying a mob to hunt down the DevOps engineer that sold management on this incomprehensible tool
They are a necessary footgun. And yeah it’d be nice if we could be rid of them, and the UI surrounding them is icky - but for new users the “good UI” has a bigger learning curve.
This is a very good note I think the important take away is that the documentation should be very clear about the potential footgun, and give users all the information they need.
I still think the mentions of these footguns on the wiki pages with little additional context do more harm than good, though.
Note that it is also not impossible to have a declarative approach and an imperative interface: I. e. nix-env -iA, nix profile install could just modify a config file which describes the current user environment and then immediately apply the changed configuration.
Indeed, gentoo does this to a degree with it’s world concept. It wouldn’t be unreasonable to take a similar approach with nix, though that would mean reworking nix profile somewhat, and it’s probably too late for that at this point.
At least for nix profile that is exactly what already happens, but looks entirely different from what one is used to in the delarative approach. It’s also a bit hidden in the inner workings, and not advertised, as opposed to say /etc/nixos/configuration.nix or ~/.config/home.nix.
If it’s to be compatible with declarative usage, though, it would still need some changes. Currently the only way to edit the declarative definition is to use the imperative commands, since it’s stored in the nix store as part of the derivation.
I made a tool for myself with similar functionality: npkg. Being able to install packages imperatively and declaratively targeting the same file is nice. But in defense of nix-env, a lot of the time if I want to quickly install a package for more time then just nix-shell -p, it comes in handy not needing to wait for my entire system to rebuild, especially on lower end hardware.
I don’t think deprecating nix-env (and/or nix profile) is is justifiable without providing a viable alternative. Home Manager is the obvious candidate, being the de facto standard way of installing programs in a user environment. However, as it stands I don’t think it’s a suitable choice to recommend in place of nix-env.
It’s a third party project, not affiliated with the Nix project (as far as I’m aware). That in itself puts a damper on things - can you really remove a feature and recommend a third party solution in its place? This lack of affiliation also means it doesn’t have the full weight of the Nix community behind maintaining it. rycee does a fantastic job, but he’s just one guy. If Home Manager were to be recommended, there would need to be more manpower behind the project.
As it stands, there are still a few areas where the user experience is a bit lacking, particularly around compatibility with flakes. For example, home-manager news and home-manager option both don’t work with flake based configs, and there’s currently an issue where you need to manually delete previous home-manager generations when home-manager switching, since new ones conflict with the older ones.
As Nix continues to evolve and gain features, for Home Manager to be a viable alternative, it would need to stay up to date with Nix features, and integrate seamlessly with them. That’s not entirely the case at the moment. in order for that to happen, it would be necessary for Home Manager to have a larger group of maintainers, and probably for the Nix maintainers to work closely with them as new Nix versions are released.
In a scenario like that where Home Manager took on a more official role in the Nix ecosystem, and was better integrated with Nix itself, and had lots of people supporting it, I could see the case for deprecating nix-env. But as it stands, I don’t think it makes sense.
I strongly agree that this would be the ideal approach. Declarative vs imperative is too often presented as a false dichotomy, we can have our cake and eat it too! There’s even precedent that many devs will be familiar with - npm install works this way.
I think in order to qualify, the declarative config needs to be designed to be ergonomically user-editable.
As a newb whose only used nixos directly and suddenly needed to install something using nix on an Ubuntu machine, I definitely didn’t want to use nix-env -iA. This is the correct answer. It’s simple, and it’s in the manual.
I have to admit, however, that I have no idea what this means
If you want to load the packages to be built from a working copy of nixpkgs
I have to admit, however, that I have no idea what this means
If you want to load the packages to be built from a working copy of nixpkgs you just run nix-env -f. -iA myPackages
This is about using a local git clone of nixpkgs. (Git terminology would be “working tree”). Which would make more sense if you’re working on packages in nixpkgs.
Recall the shortflag -f. is --file .. Whereas, you can check the nix manual nix-env - Nix Reference Manual and see that the default option is ~/.nix-defexpr, & how nixpkgs relates to the default ~/.nix-defexpr/channels/nixpkgs.
I find I can’t justify switching to coworkers unless there’s some unique selling proposition.
I think we should do away with imperative installation… sort of.
tl;dr only offer declarative installation but make it more convenient with familiar “imperative” tooling
I think there should only be a declarative option and nix profile install should act like npm install and add the dependency to something like profile.nix and either instruct the user to run nixos-rebuild switch or run it for them.
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.
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/
I think the important take away is that the documentation should be very clear about the potential footgun, and give users all the information they need.