When to use `nix-env` over configuration.nix (new to NixOS)

I’m a longtime Linux user, (mostly Debian & Debian downstream distros), getting used to NixOS.

I’m trying to understand:

  • Under what circumstances should I use nix-env to install packages over specifying packages in /etc/nixos/configuration.nix file? I see nix-env mentioned but also it’s recommended that it not be used. Why does it exist then? Is it just for users without root or admin privileges to be able to install software?
  • I’ve heard people mention that using nix-env “doesn’t give you the benefits of nix”.
    – I know that installing software with nix-env won’t effect the boot version options.
    – I know that the generations are managed separately
    – but what all exactly is meant by “the benefits of nix”? Is it just those or something more?

Further context, as I’m using my system and learning NixOs and installing software, the longer my builds take when I run sudo nixos-rebuild switch. I’m inclined to use nix-env to install further software that doesn’t need to necessarily be installed on the system level to cut down on build times but I can’t help feeling like I’m doing something wrong, or is the recommended way of using NixOS truly to install everything possible through configuration.nix and make thy peace with longer and loooonger build times? If it is I can accept that, I just wanna make sure I’m using my system to it’s fullest.

Also apologies if the answer to this is obvious or front and center in the docs, I have it on my agenda to start working through the nix docs but I haven’t got around to it lately. Do feel free to include recommended reading in the docs or otherwise if you’re so inclined.

Thanks y’all!

1 Like

It’s vastly over-simplifying things, but the basic reason there are both is that nix-env -i is for nix on other platforms, where you can’t manage the system more cohesively with configuration.nix. It’s an imperative “install thingX” method, equivalent to something like brew install thingX when nix is used as a third-party package manager.

As you go on, you’ll learn that the concept of “software being installed” at all is more nebulous, and there are many ways of managing what’s downloaded, what’s upgraded when, and what’s visible in the path in which context. Coming from other distributions, where everything is usually “installed” into the single global system, is something you will ‘unlearn’ to a degree.

Many of those other methods apply equally well on both NixOS and nix-on-other-platforms cases, and using those may also be preferable to nix-env, and so it will somewhat get left behind. Examples include:

  • pulling something in to a project devshell, automatically with direnv, to get versioned and updated as part of a project rather than host schedule.
  • managing your own applications via home-manager rather than via either system packages or nix-env
  • using nix-shell, nix shell, nix run, etc for things you use infrequently, rather than “installing” them “in case”
2 Likes

Mostly the ability to define your installed packages in a version controlled configuration file, that you can then use to reproduce your set of installed packages on another machine. If you install a bunch of stuff with nix-env, it’s not so easy to reproduce your setup.
In my opinion if you’re not concerned with this benefit and just want to use nix like an apt or pacman equivalent, using nix-env is a perfectly valid choice.

1 Like

Check out https://stop-using-nix-env.privatevoid.net/ for some quick explanations on why nix-env should be avoided in (almost) all cases. Much more detailed discussion is in this thread.

For your specific questions:

  • On why nix-env exists in the first place:
    It is useful as a “low-level” plumbing command for other tools (e.g. Home Manager). These tools (should) have a high-level API that retains one of Nix’s main features: being able to define your NixOS configuration (among other things) in configuration files, written in a declarative language.
  • Benefits of Nix:
    As stated in the first point, one of Nix’s primary strengths is its use of declarative configurations. In practice, for NixOS, this means (nearly) the entire operating system is defined in /etc/nixos/configuration.nix and whatever other files configuration.nix imports. This declarative approach has many benefits, which I assume you are already aware of since you’re already experimenting with NixOS. Using nix-env instead of modifying /etc/nixos/configuration.nix to permanently install things go completely against this idea. But see below for temporary installations…
  • On long build times:
    When you add new packages to /etc/nixos/configuration.nix there is not much you can do to reduce the potentially long processing time. Subsequent nixos-rebuild switch commands that you run just to update already-installed packages should complete fairly quickly. If you want to install something temporarily, use ephemeral shells.
4 Likes

It still has very severe flaws even as an apt replacement, sadly, most of which all users probably fall prey to unwittingly. Give the site linked by @testplayername a read, I think it can genuinely be called broken.

nix-env is still worth understanding to know how nix things work under the hood and to write tooling with yourself, without targeting experimental features. Avoid it otherwise.

If you really need it, at least be very aware of its issues. It’s probably still an ok tool to learn with when you’re starting out if you’ve been warned about the problems.

I hope nix profile is stabilized soonish so we actually have a viable replacement for it, but that’s likely still a few years away.

2 Likes