back
2 comments
Now, don't get me wrong, I don't have a horse in this race.

But as a complete outsider, this doesn't fill me with confidence. If Wikipedia is to be believed, NixOS was launched in 2003, so 18 (!) years ago, I assume that's when Nix was created.

The issue mentioned seems quite basic and you're replying that it will be fixed in a new Nix CLI.

This seems like a basic QA fail, I wouldn't want anything like this within 100 km of any production environment I'm working on.

I imagine Nix is underfunded, but few projects come back from stuff like this. If they can't get their stuff together in almost 2 decades, who will ever trust them that they ever will?

It's not a bug, it bad UX, and new version of nix command line is meant to fix the UX. Or more correctly, it is a bug, but the proper fix is to remove that functionality.

Basically the nix repo unlike other package repos it isn't flat it is a tree of many different derivation. A lot of them even repeats. For example parent poster had problem because he installed version of nix that used musl instead of glibc. You can similarly reference packages that cross compile for different platforms. For example you can install Raspberry Pi version of a package. But if you're not running RPI that binary won't execute on your computer.

Now, nix-env by default tries to guess where in that package tree application with given name exists and then installs it.

This probably worked well early on when nixpkgs repository was small, but as it grew, they added cross compilation or other variants like installing packages with musl etc. It doesn't make a good guess. That's why now -i and -u should be followed with -A option, which disables the guessing and provides a path in the tree, so the command should be (besides being accurate it is also much faster since nix doesn't need to scan the whole tree):

    nix-env -uA nixpkgs.nix
Or actually the recommend way to update nix itself is:

    nix upgrade-nix
The nix-env command is also mostly used as a bridge since most new users will be familiar with that interaction. People who get past the learning curve no longer use nix-env, because it is not the "nix way" of doing things, which probably explains why the command is still the way it is, and the new cli command organization (which is using just single "nix" command kind of like you use git, doesn't have nix-env functionality)
But it works as expected by someone understanding the underlying system, and some existing advanced users do use it. Backward compatibility is important already.

It’s not like you have found a bug in the way the fundamental package handling is done which hasn’t been fixed for a long time, so I don’t think it’s fair, especially over an in context negligible nitpick.

nix-env (including nix-env -u) is purely a user-facing UI helper for new users. One would never use it in production, or even for development, even when it was first released; it's only ever been for new user onboarding. So it's a bit low priority, since it has no production impact and experienced users don't use it...
Today's new users are tomorrow's experienced users.

I guess it depends on what Nix wants, if it wants to remain a niche system, then things are good as-is.

Though, on the other hand, the comment says a new CLI is close to release, so I guess people are trying to improve things.

Though, on the other hand, the comment says a new CLI is close to release, so I guess people are trying to improve things.

I don't want to be too critical, I love Nix. But the experimental new UI was already in development (and available) when I started using Nix in 2018. It has also changed quite a lot recently and is now very strongly tied to flakes. However, the flakes RFC was withdrawn [1]. Given that flakes are a large change, I'd expect (but maybe I am wrong) that there will be a new RFC.

At any rate, I would be surprised if the new CLI with flakes are close to release.

[1] https://github.com/NixOS/rfcs/pull/49

I believe it is only withdrawn for further work on it.
Yes. But since there was an initial RFC, I would expect there to be another RFC when flakes are ready.
I agree with your reasoning and the reason this is hard to change is similar to Python 2->3 transition.

If it was about 50 users, we could just do it.

Since there are many users, it takes a while to move from one UI to another.

Understandable. Good luck with the transition!
What an absolute nightmare. Just from reading this one comment thread I will never, ever try this tool. It sounds like there are a thousand ways to achieve a given task and no one can agree which one is "right", but everyone can agree that the way blessed in the official documentation most certainly isn't.
You are free to draw conclusion from 2 comments, but it is not too wise.

It is most definitely not a Windows Store one click user-friendly tool, but it is infinitely powerful, allowing you to run only one specific app with even something like a patched libc, upgrade the system and rollback wherever you want, it is the only package manager that doesn’t leave lingering files all around your system.