And I didn’t intend to suggest that the imperative approach be removed or anything, though my wording could have been clearer on that. nix profile is surely sticking around, even if nix-env should probably disappear at some point due to its semi-broken nature.
What I have a problem with is that the imperative approach is effectively raised above declarative approaches by being the sole method distributed as part of nix itself. Nix-standalone needs a declarative package management system that works easily for newbies out of the box, and is presented in documentation as a suggested way to manage packages with nix, if not the suggested way, with the imperative system being secondary. It would help if the default config file structure allowed “dumb” cut-and-paste substitution between it and environment.systemPackages / home.packages.
nix-env -iA is currently seen (by newbies and outsiders) as THE way to install packages with nix, and that really needs to change.
Distrowatch’s webmaster jessie reviewed NixOS 22.05 and had many issues (link to the review)
I was surprised to read about nix-env in multiple places, and as the author had issues such as bad desktop integration, I wonder if this could be related to the use of imperative package management instead of declarative global wide?
but it took a few minutes for Nix to search for a package.
Yes, but just because nix-env is broken and they didn’t come across the warnings that you need that pesky -A flag, not because imperative management is inherently broken.
Still a shame that they had this experience. It’s silly, but will probably persist until nix-env is abolished by nix profile.
I suspect a fair few of the other problems might have been legitimate issues with specific packages, but I don’t personally use plasma.
Sadly, it looks like it might be many years until that particular set of problems caused by nix-env is fixed, unless there is appetite for adding a warning when -i is used without -A or something.
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 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.