New users using Nix (not NixOS) wrong

The nix manual introduces nix-env immediately (, so that’s likely what new users will use, hitting issues such as packages that don’t work at all (, package names that install packages that don’t work over packages that do (

The declarative package management described in the nixpkgs manual ( also refers to nix-env, setting the expectation that one can use a mix of both, or use nix-env first to try out packages, and add them to the declarative package management later.

These sharp edges are both tricky to work around / debug, and hard to avoid, making using nix as a package manager on a non-NixOS Linux distro or macOS hard for new users.


Personally for package installation, I disliked using nix-env so much that I only use nix-shell and home-manager now. also avoids the huge amount of, “oh yea, I installed that a long time ago, but don’t really need it anymore” scenarios


At my organisation we’re using Nix mainly on macOS to manage development environment and it’s been working great, but we’ve struggled quite a bit at the start.

I’m now looking to replace brew with Nix for system level package management, installing both UI and command line applications, and I’m hitting new issues, especially from a usability perspective.

If the learning curve for using nix as a system level package manager is too steep we won’t be able to onboard new users effectively.

1 Like

What is worse, it shows nix-env -i without -A.

I started working on adding -A everywhere but there was just so many of places and then the manual was switched to Markdown :unamused:


I agree. The first time I tried Nix, I uninstalled it within the hour. I followed some documentation that suggested nix-env -i. Installing a package took a long time as I saw nix gobble up a lot of memory. I concluded that Nix was a bad/inefficient package manager and moved on.

My first impression of Nix was not very good thanks to nix-env -i (without -A).


Your experience and many other comments (as well as my own impression of getting into nix) make it look like there is a sentiment of removing nix-env from the documentation. There was a valid point in the other thread, that without either root access or home-manager, nix-env is the only way to get stuff installed permanently. I also repeatedly observed people rooting for home-manager to become part of nixpkgs or at least the blessed userspace configuration tool.

I would like this conceptual homogeneity: nix should always be used declaratively, for the system (NixOS) and optionally for the unprivileged user (home-manager). I don’t think it is worthwhile or even beneficial to integrate anything into each other.[1] Just improving the documentation to lead people to home-manager directly, would prevent the kind of confusion and disappointment about the maturity of NixOS I had when reading the infamous wiki or third parties something along the lines of „Do nix-env, if you think that’s stupid, well, there is home-manager or something else, but then you’re on your own“.

So yes, I prefer to bless home-manager, as this appears to be the most efficient thing to do.

[1]: OT: nix is exactly the tool to enables decoupling and separation of responsibility. I always found it weird how mind-bogglingly large the officially supported package set is. Why not have people take care of language ecosystems, areas of interest, complex individual packages, etc. on their own, and let them base their integration efforts on stable releases with strong compatibility guarantees within a release branch? Then one could either endorse usage of those third party collections in the documentation (and eventually systematically, by including package or option search results transparently for example) - or just let the ecosystem manage itself, people will have to evaluate what is alive enough to rely on anyway. NixOS would be a platform, not a planet-sized agglomeration of packages with too few people to handle them all.

1 Like

Or, maybe, lorri. Or, maybe myEnvFun. Unclear how little mention one should give to alternatives here.

Then again, nix-env seems to be behind even as the imperative option, nix-env -iA does not have a matching -eA in any form (unlike some alternative imperative Nix wrappers, actually)

The more you decentralise, the harder it gets to answer «so what this core change breaks, actually?»

Even the modest Nixpkgs-NixOS split during migration from SVN to Git did not stay.

1 Like