If I read the documentation correctly, nix profile is still experimental, right?
7 Likes
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.
2 Likes
I also agree Nix should officially support a home environment configuration tool. Guix now has https://guix.gnu.org/manual/devel/en/html_node/Home-Configuration.html
3 Likes
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.
12 Likes
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.
4 Likes
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.
11 Likes
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 /etc/nixos/configuration.nix or ~/.config/home.nix.
1 Like
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.
3 Likes
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.
1 Like
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.
3 Likes
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.
4 Likes
What keeps Home Manager a separate project from nix/nixos? Why is it not more integrated?
this has been answered earlier in the thread
1 Like
2 Likes
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
nixpkgsyou just runnix-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.
1 Like
working copy should be renamed to local copy I suppose
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.
6 Likes