> I've never really understood the use case for nix-env.
If that's the case, perhaps `nix-env` shouldn't be mentioned as the command to use to install packages on search.nixos.org?
I checked the NixOS manual right now but the last time I did, it instructed to use nix-env to install packages. The declarative package management using configuration.nix wasn't highlighted before as it is now.
This is exactly the kind of thing the parent comment mentioned. I'm not willing to go through these kinds of papercuts to get whatever NixOS has to offer with its radical changes.
Oh, and the nix package manager is still unbearably slow. It reminds me of my (unpleasant) time using dnf. Once you're used to package managers like apk and pacman, its an extremely jarring experience to stare at your screen and wait for a package to get installed.
> If that's the case, perhaps `nix-env` shouldn't be mentioned as the command to use to install packages on search.nixos.org?
Yes, you should pretend this command doesn't exist.
There is no need to be using NixOS to do so.
> Oh, and the nix package manager is still unbearably slow
This doesn't match my experience so I wonder what you're doing differently. It's only slow if you're missing the cache, either local or remote, as then you need to build things locally, unlike apk and pacman which install only prebuilt packages from repositories. Nix is fundamentally different to those package managers. I find it very snappy.
> I saw talk from one guy who wanted to make the Nix package manager use commands that were more like in other package managers.
Did any of this happen?
Yep, that happened, at least somewhat. Most things that you would want to do that used to be argument soup with `nix-env` now uses a program just called `nix`. For example, searching is now just `nix search <query>` instead of whatever the `nix-env` incantation was
> Now if we can just get the UX together, it will be incredible.
The crux of the NixOS issue right here. I tried NixOS a few times, even this past weekend, and it was such a pain that I gave up each time!
I am planning to integrate Nix (the package manager) into my recent fresh OS install if I have some time this week. I want to use Nix to have, at the very least, a controllable way to install and remove toolchains of different versions in a reproducible manner; if I can swing it I am going to use it to install pretty much anything that requires any sort of configuration care (the rest I'll just use apt). I also want to integrate more tools like asdf or pyenv which help with that, but I prefer if I could do it all through one package manager like Nix. I finally separated my /home into another drive this time, so that'll be nice for future re-installs.
> I think the problem with Nix is that it is actually not a package manager but a build tool (that provides some package management utilities). People try Nix with the assumption that it should be as easy as apt-get (for example), but found tutorials with a block of code in a weird language...
Indeed, I've been using Nix for many years (on Ubuntu, NixOS and macOS), and I now find the apt-get style 'considered harmful'.
Instead, I define a single Nix derivation ("package") which provides everything I want in its 'bin/' directory, e.g.
with nixpkgs;
buildEnv {
name = "my-macbook-programs";
paths = [ bash gimp /* etc */ ];
}
The nix-build command creates a symlink called `result`, so I put `/path/to/my/git/repo/result/bin` in my $PATH.
> Is [the benefit of this approach] just a matter of it being quicker to do nix-env -iA instead of updating your config and running home-manager switch?
That's definitely a factor. I think since I keep my Nix configurations in source control, somehow modifying the configuration feels more ‘official’, and it also usually comes with extra steps like committing and pushing.
The other thing I like is that it makes it very easy to tell if I actually want/need something: if I find myself installing something over and over (because I periodically purge my profile), I know for sure that it's time to add it to my config. This way I end up pulling less crap I don't actually use into my setup in an enduring way.
Maybe I'd also feel the same way about invoking things via `nix run` or `nix-shell` over time, and that would motivate me to incorporate them into my config ‘for realsies’ by declaring them.
> instead of updating your config and running home-manager switch?
I'm not currently a home-manager user on NixOS. Before home-manager was a thing, I used to define groups of packages using buildEnv and store them in an overlay for very simple de-facto declarative package management, so something like:
nix-env -iA pxc-tui-apps
would install my whole CLI environment at once, and then on NixOS, I'd include `pxc-tui-apps` in my `environment.systemPackages`.
I'm switching to home-manager in my new setup, but one thing I still like about `nix profile install ...` (the flakes-based/next-gen replacement for nix-env, currently) is that it's user-mode/unprivileged, and it doesn't involve rebuilding my whole system (or anything other than the dependencies of just the package I want), even if my nixpkgs checkout/channel/flake registry or whatever has changed. `home-manager rebuild switch` is also unprivileged and also doesn't involve updating my whole system, but unfortunately home-manager doesn't support flakes just yet. You can use it on flakes-based setups on NixOS and macOS via the home-manager NixOS and nix-darwin modules, respectively... but then you're giving up the other benefits I like, because you have to invoke nixos-rebuild after all!
If `nix profile` were some day removed along with `nix-env`, but I had a user-level declarative environment management tool (like home-manager or something more tightly integrated), I could probably get by with just a little discipline about how I choose to edit my configurations and manage sources of Nix expressions and be pretty happy.
But I think the problems with `nix-env`/`nix profile` are pretty solvable, and I think lacking any imperative solution at all will likely put some ‘winnable’ new users off.
I do agree that `nix-env` itself sucks and needs to go, though. `nix-env --upgrade` doesn't really do what people expect, and there's no real reason to use/prefer it over just removing/reinstalling a package. The way that `nix-env` thinks about versions is basically insane, since Nixpkgs doesn't have any real version metadata and `nix-env` just parses attribute names to get the versions back out. `nix-env --query` is clunky and slow (but the new `nix search` is awesome and crazy fast!). `nix-env` was a cool thing for its time, and it's actually how `home-manager` manages its profiles on the backend (which is why flake support is still lacking; enabling flakes disables `nix-env` for your user). But it's like an imitation of `rpm`, and it was made before Nix had a real userbase and opportunities to think about what operations/abstractions/metadata were desirable at that level.
One of the things that's cool about Nix's design is that its design allows you to just bypass the hardest and most annoying problem that faces traditional package managers: dependency resolution. If you want a package manager that's guaranteed to give you solutions that are correct and complete, you need a SAT solver for dependency resolution, and that's NP-complete. By leveraging its quasi-content-addressable derivation approach, Nix gets to avoid resolving dependencies like traditional package managers do— the thing you need is the thing you were built against, and that's that! Similarly, by leaning hard into the Nixpkgs monorepo so that almost all packages live on it and all third-party package sources are built as de facto overlays on top of it, Nix has been able to totally avoid having to think about versions.
Compared to formats like DEB or RPM, Nix packages have very, very little metadata. Nix packagers don't have to declare things like acceptable version ranges for dependencies, what packages provide, what package names ought to be considered equivalent, what other packages it's incompatible with, or even what version number a package has. But `nix-env`'s `-q`, -i`, and `-u` options all imitate the `rpm` CLI, where all of that kind of metadata is necessary and present. And `nix-env` makes all that stuff work by assuming the structure of Nixpkgs and operating on Nix attributes representing packages directly. And it doesn't really make sense in the Nix world as it exists.
Flakes is the first attempt to revisit all these questions the community has basically punted on like ‘how do we want to relate packages to each other in a way that's not monorepo-centric?’, ‘what kind of metadata do we actually want to have for publishable Nix source package artifacts?’, ‘how should Nix code repositories advertise what features/tooling (packages, shell environments, modules, overlays, whatever) they support?’, ‘do we want Nix to actually be able to reason about versions?’, etc. (This also possibly reintroduces the question of dependency resolution. Hopefully not?) I think once we have real, considered answers for questions of that kind, grounded in the experience of the community so far, we can build an imperative frontend to Nix that makes sense and is nice to use.
> The problem is that it lulls you into thinking it serves the purpose well enough and then eventually things break. Then they get more broken. Then you can't figure out which thing you installed is breaking things. Then you finally do and can't figure out how to uninstall the thing that broke things.
I'd rather phrase this as: the 'problem' with `nix-env -i` is "I forgot I did that" or "I didn't know I did that".
I believe since the command is the easiest thing to do with Nix, and many people will try it and maybe got back to non-Nix package management, it disproportionately leads to newbies asking for help; thus, the general mood against it.
> Yeah, the hard part is maintaining a file just to have the tools you want
I'd be okay doing that to install packages but what I don't like is the N number of ways to install packages. Do I use nix-env? Do I use the new nix CLI? Do I make an entry in configuration.nix? Do I use this thing called flakes which is marked as experimental but almost everyone seems to be onboard with it?
There's no central and definitive source of documentation either. There's the official NixOS website, nix pills, nixos.wiki, blog posts from prominent developers, and other sources I don't remember.
> Oh, I'm also not a fan of how unbearably slow the nix package manager is compared to pacman.
Building a declared environment takes quite a while and switching a NixOS or home-manager generation takes even longer. It was my main complaint about NixOS when I was starting out.
The thing I realised though is that the main scenario where you actually need the speed is when you want to try things out and for that, Nix' ad-hoc environments are much better suited.
When I want to try a new program (btop for example), I simply run `nix-shell -p btop` rather than adding it to my declared environment and sitting through a `nixos-rebuild test`.
That's usually faster and, more importantly, cleaner than installing the package to a global environment with a regular package manager.
> I saw talk from one guy who wanted to make the Nix package manager use commands that were more like in other package managers.
I'm guessing this is about `nix` and `nix-env` having poor interfaces and lacking e.g `nix install` – those aren't _really_ meant to do package management, because it's an imperative approach akin to Apt. I haven't touched `nix-env` for actual package management in over a year now.
You should instead be writing your system-level package dependencies and services in your configuration.nix, your user-level package dependencies and services in home-manager's home.nix, and if you just need to use a package quickly, you should use `nix run nixpkgs.hello -c hello` or `nix-shell -p hello`, and if you're trying to set up a dev env for a project you should be using direnv or lorri. nix-env pollutes your environment and causes headaches when/if you add the same packages you have installed there to your declarative files.
>I couldn't use any of my NPM skills with the Nix package manager.
You can – look into direnv and lorri, they let you handle system-level dependencies while NPM handles its own libraries, on a per-project basis. This is IMO the best contemporary way to do a developer environment.
> I still don't get why "first steps with Nix" has to include installing packages permanently.
Because if I don't know nix (which, you know, would be why I'd be reading introductory material) I'd be looking to use it, and my basis would be to do would be the way every other distro works.
And if I have to type `nix-shell -p python38` every time I want to run Python and `nix-shell -p vimMinimal` every time I want to edit a file, the experiment is not going to last long.
> So the website recommended you to read a page containing introductory examples. Not sure why you insist otherwise.
I'm not "insisting otherwise", I'm observing that it's confusing, utterly useless, and provides no real guidance towards improvement. And it's where the site told me to go as my second step into nix.
But apparently you're perfectly happy that this is what the "first steps with nix" should be (after having berated me for going there), so... proving the point I guess.
> What? The there are far more chapters in the Nix manual than just the three you mentioned.
Have you actually looked at them? ever?
1 is a quick overview of the entire thing, none of it actually helpful.
2 is a few basic commands expanded upon in (4)
3 is a lot of time spent on installation details
4 is where the meat starts, "You can upgrade package" is 4.1, "profiles are a thing" is 4.2, 4.3 is "nix will eat your disk space" (useless to a beginner), 4.4 is "channels" (even worse), 4.5 is "sharing packages between machines" which could not be less useful at this point./
5 is, as I said, "the nix language" covering the basics, with 5.4 mentioning derivations and going into plenty of details, none of them actually useful or telling a beginner why they should care
Following which we reach 6.1 "remote builds.
From a beginner's perspective, tits on a bull are at least funny, the nix manual doesn't even have that going for it.
> Main reason for leaving was that Nix package maintainers have to heavily patch all software.
Any widely used distros do this. Plus, the statement that you have to patch all packages is false. In many cases, all you have to do is set the right build flags and environment variables, which is handled by standard helpers in nixpkgs.
I'd also like to add that nixpkgs has the most extensive testing for packages compared to any other distros I've seen.
> Packaging for nix is more like porting software to another operating system.
Dramatic, but again, simply not the case.
> note that they have automated tools for patching the most common problems, so the problem is even worse.
This is a good thing. Manual patching for the most common problems isn't sustainable, especially if you maintain a large number of packages. Just ask packages maintainers of any major distros.
> I was able to merge some pretty large patches to nix-packages from an anonymous and sketchy-looking github account, and they weren't scrutinized much
All packages in nixpkgs has a mandatory review process as you should very well know. As scary as you make it sound, I'm pretty sure at least one committer have taken a look at your code to see if there was anything malicious in it.
> Moreover, Nix breaks the chain of trust for the language packages.
After a quick look, it seems like you can still use the unmodified erlang package manager? The patched version you've mentioned seems to be there for facilitating creation of Nix packages and it looks like the main intent was to remove the ability to download packages from the internet. If this is the case, it wouldn't be a security problem at all because the dependencies would have to be prefetched and their hashes precomputed.
> /nix directory is readable by all users, so you cannot use Nix to manage secrets
Why not store secrets in a private location, just like you would on any other distros??? What is it that other distros have that Nix is missing? I'm not seeing your point here.
With that being said, note that this feature is being worked on, and systemd very recently introduced a new feature for secrets management [1].
> You cannot install opam packages without dealing with incompatiblities, you cannot easily install games from Gog without dealing with incompatibilities
Matbe take a look at buildFHSEnv.
> do you really need such degree of reproducibility for your very own dev machine?
Yes, it saves me from having to do a clean install of my system every few months. I haven't done a clean install at all the last few years since I started using NixOS.
> It's a language, and thus the language has may expressions that result in the same outcome.
First it's a distribution and a package manager, and the guidance regarding these is sub-par. Especially with what there is of documentation being split between the old and new UIs, then being told about flakes but that they're experimental so it's not clear whether you should or should not use them.
Is that useful? I'm sure to somebody who already knows what they want out of nix it is, but the first thing I'm told is that shell environments exist and are useful to "use the tool without having to install the software.". Ok, but what if I want to install the software? Then there's listing of what's essentially a magical invocation out of nowhere:
I can understand that (or at least reach what I assume is an understanding), but there's no real explanation to give me knowledge to expand upon, if anything the explanations are worse than useless:
> We create an ad hoc environment with $PYTHONPATH set and python available, along with the django package.
thank you very much, that confirms I'd about interpreted the line correctly, but you've not told me what `withPackages` is or where `packages.django` comes out of so I'm not really helped.
And apparently the next step is "declarative and reproducible developer environments", or possibly "towards reproducibility: pinning Nixpkgs"? Or even better, "To quickly setup a Nix project read through Getting started Nix template", I have no clue what a nix project is or why I'd want one.
There's not just a step missing here, there's an entire floor, possibly building. It's like the nix community saw how git is taught and went "we can do worse".
> I wish the next generation of linux has a single package manager :(
Package management used to be my biggest frustration with computers. A couple years ago, I switched to nix [1][2] and now use it across all my unix-like systems (not sure how well it works on Windows, I haven't tried). Most under-rated piece of software I use, I'm surprised it hasn't blown up yet.
> You have to learn a new OS because a lot of your prior Linux knowledge no longer applies.
This is what confused me the most.
Nix (CLI tools / language syntax)
NixOS (A Linux distro that has CLI tools, but also some CLI tools that are only available on this distro and not others, aka "nix" doesn't really work on Debian)
Flakes vs "configuration"
I just wanted to like "terraform apply" a system configuration on my Debian install.
People are obsessed with Nix because you can manage your config for their local system
Ok... Ansible has existed for 12 years? And you can use it on Debian/don't need a full OS/distro from the ground up (NixOS)
But people will come out of the woodworks to tell you how you don't understand, you're wrong, you're missing the point, Nix is the greatest.
>> ... and not have it installed globally is amazing.
Yah, the more I think about it this is the biggest selling point to me.
>> Of course, you can use the nix package manager on any Linux distro and even macOS if you want a gentler introduction.
I actually never thought deeply into nix NOT on nixos (I've probably been conflating the two). As an infra/devops-y person I can think of a lot of cool use cases off the bat in the server-space (theoretically anyways, I've a feeling the details would be quite the devil). But, except for the case of developing for such a system, I'm struggling to see a use case that warrants it in the desktop realm. (I need to meditate on this one..!)
> My own problems aside, I would expect from a tool marketed as something that helps you keep your environment clean to not litter my disk with a ton of hidden files and directories spread all over the filesystem.
On non-nixOS, I think the changes Nix makes are:
1. puts the majority of its stuff under /nix
2. in the user directory, puts some files under ~/.nix-channels, ~/.nix-defexpr and ~/.nix-profile
3. modifies the default shell script /etc/bashrc or so, with some stuff under /etc/nix.
4. adds multiple users nixbuild1 ... nixbuildN.
The uninstall command given in the manual is a one-line:
What I was complaining about was the difficulty installing a specific package version. That's trivial with other build systems, but not Nix.
> I don't use [package managers] to install dev dependencies.
I'm under the impression that most people do. Either way, I see the main advantage of using Nix to be setting up dev environments without installing a bunch of global packages, or dealing with a mess of files. Unfortunately, as a user, I find it to be much more of a hassle than it needs to be.
> Huh. I think this is the first bad experience with NIX I've ever heard on HN.
Strictly speaking "Nix" may refer to two things, and I'm not sure which thing either of you are referring to, nor if you two are referring to the same thing.
Personally I found the nix package-manager a bit odd, but to me that was not a deal-breaker for trying out NixOS. The bigeset problem for me was lacking packages... I was however willing to help the community out by trying to package the things I needed which wasn't already provided for.
But then I had to use the Nix language. And that was a great displeasure, and I ended giving up NixOS all together because of this one pain point.
And to address your comment: I think I've seen similar comments on HN at regular intervals. It's definitely not a one-off comment.
If they had used another more standard language (like LISP!) I would probably still be on NixOS as my main OS.
In the long run, I really hope Guix manages to get something good going. My biggest concern for Guix is that they will restrict the available packages by being overly zealous about package-licensing (like everything the FSF does).
If that's the case, perhaps `nix-env` shouldn't be mentioned as the command to use to install packages on search.nixos.org?
I checked the NixOS manual right now but the last time I did, it instructed to use nix-env to install packages. The declarative package management using configuration.nix wasn't highlighted before as it is now.
This is exactly the kind of thing the parent comment mentioned. I'm not willing to go through these kinds of papercuts to get whatever NixOS has to offer with its radical changes.
Oh, and the nix package manager is still unbearably slow. It reminds me of my (unpleasant) time using dnf. Once you're used to package managers like apk and pacman, its an extremely jarring experience to stare at your screen and wait for a package to get installed.
reply