The declarative package management described in the nixpkgs manual (Nixpkgs 23.11 manual | Nix & NixOS) 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.
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.
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.
I mean i nearly 100% of the time only use Nix through nix-env, for the simplest reason that i have never been able to understand how it should be used without it on a non NixOS setup. Like at all.
And home-manager is still, as of last time i checked, marked as experimental and being able to break in atrocious pieces at any point in time.
If we want to change how nix-env works, we need to start by making it easy and obvious how to use nix on a non NixOS system without it. I still do not know how to do that…
It’s really easy to avoid installing packages with nix-env by simply pulling them into an ad hoc shell when desired via nix-shell -p $package or nix shell nixpkgs#$package with flakes. When you are done with whatever package you need, you simply exit the shell.
For more elaborate usage, say for a project, I use a combination of a shell.nix and direnv to pull all project dependencies and set any necessary variables.
Not sure where you got that impression but I have been using home-manager for over 3 years now and only ran into a bug once or twice which was promptly fixed upstream.
Those sound like issues prevalent in the Nix language itself. Specifically in the module system implementation. I’ve been using Nix for years now and still occasionally run across an infinite recursion error that is challenging to debug from time to time. This isn’t inherant to home-manager specifically. In fact, home-manager simply reuses the same upstream module system used by NixOS itself.
Sounds like rycee is just trying to warn newcomers of the challenges that come with working in Nix as it stands right now. That’s not to say that this situation shouldn’t be improved. But it is something that would have to be improved in either the module system, some sort of future replacement to the module system, or the Nix tool itself.
Nobody is saying you have to use it, but I’m gonna have to disagree. using home-manager isn’t much different than using NixOS or nix-darwin. They all use the same machinery under the hood and in fact home-manager can be used from NixOS for this exact reason.
I don’t see how newcomers can learn anything substantial if they attempt to avoid a gigantic part of Nix’s ecosystem. Nix can be used as a traditional, imperative package manager for simple use cases, but it’s real power lies in it’s declarative config language, and currently, the module system is a big part of that.
Of course, you can still create isolated shell.nix environments, and if you wanted to avoid the module system, you could probably just drop a shell.nix in your HOME directory and use direnv to invoke it automatically, pulling in any packages you might like to have specified declaratively in your user session.
I totally agree with you in there, i think i am badly explaining myself. The problem is that none of the “good” ways are explained in a way that would make a newcomer feel that it is the right way to do it.
If you want newcomers to do it the “right” way you need to make it obvious it is the right one and make it as easy as possible. Right now, this is not.
Everyone suggests home-manager to newcomers all the time but home-manager isn’t an “official” part of our ecosystem. The nix community needs to adopt home-manager so it can become a first class citizen, built right into NixOS, and not display scary warnings on its homepage. @rycee once told me that the scary warning is just to scare away people who would be a support burden on him, which is more than fair. @rycee doesn’t have time to support every newcomer who has a question about home-manager, that should be the job of the community.
Almost all OSS licenses have explicit wording around not being liable for any damages, or providing some sort of warranty. Generally, there is good faith that the OSS you consume isn’t going to be deleting random or target files. I think the wording in home-manager is just being in-your-face about it, if you want, you can read the logic of the home-managerscript. All it really does is evaluate the modules, create a new profile, then apply it in your home directory.
