If I read the documentation correctly,
nix profile is still experimental, right?
If I read the documentation correctly,
Yep, it’s part of the nix 3.0 CLI work. There’s a rough roadmap for it here: Nix release schedule and roadmap
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 also agree Nix should officially support a home environment configuration tool. Guix now has Home Configuration (GNU Guix Reference Manual)
I won’t defend the use of
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
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 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.
It is experimental, so it’d certainly be possible.
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
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 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
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.
What keeps Home Manager a separate project from nix/nixos? Why is it not more integrated?
this has been answered earlier in the thread