I know imperative usage is not really considered the ideal by the Nix community, but we’re even just having issues doing basic stuff like:
nix profile install nix/2.6.1
Where you end up getting an inscrutable error like:
[1.2 MiB DL] querying source on https://cache.nixos.org
[1 copied (90.5 MiB), 17.2 MiB DL]
error: packages '/nix/store/zw68c3xydx158ldhz6a2va1j7n9712cm-nix-2.6.0/share/bash-completion/completions/nix' and '/nix/store/lf71w8bsmj6pijwxcw12s272fimxqwv1-nix-2.6.1/share/bash-completion/completions/nix' have the same priority 5; use 'nix-env --set-flag priority NUMBER INSTALLED_PKGNAME' to change the priority of one of the conflicting packages (0 being the highest priority)
I’m aware that the priority flag has been added to nix profile as of Nix 2.9.0, but IMO that’s just moving around the deck chairs— at the end of the day, this is a ghastly user experience, particularly since AFAICT the way to fix it is to nix profile list, look for the offending entry’s store path, and then nix profile remove it. Couldn’t there be a flag on nix profile install that automatically de-prioritizes (or even removes) an existing package that’s in conflict?
1 Like
We stumbled onto something similiar in the review of the PR: https://github.com/NixOS/nix/pull/6522#discussion_r873673782
If you could open an issue on nixpkgs about that that’d be great.
Is this a nixpkgs issue, though? IMO this is an issue with the package manager itself not supplying a pathway to upgrading a flake-based package (or maybe any package at all?) within an existing profile.
(Also, thanks for your contribution! I appreciate that it does indeed improve the situation and didn’t mean to drag you for it— I’m just in the position of trying to evangelize Nix to a skeptical crowd inside my company, and these kinds of warts are super frustrating to have to explain.)
Yes, we talked about opening an issue in the nix repo.
There also is a way to upgrade packages installed into a nix profile with nix profile upgrade
Okay, I could see how that might be useful in some cases, but it’s not really solving the case of how to upgrade from an explicit tag to another explicit tag. There almost needs to be a “replace” option so that you can do:
nix profile replace nix/2.6.0 nix/2.6.1
However, that still puts the burden on the user to remember what they previously installed, or to pick it out of error messages or the list output. So really, the better option would be for the install verb to just do the right thing and notify the user, eg:
$ nix profile install nix/2.6.1
NOTE: Removing nix/2.6.0 from profile due to conflict with newly-installed package.
If this isn't what you wanted, run `nix profile rollback` to restore previous state. Pass
the `--remove-conflicts` flag to suppress this message.
I’ve run into this a bit, too; although nix profile upgrade suits my use case.
My understanding of the nix terminology: nix/2.6.0 is a user friendly way of writing a flake reference. The nix part refers to the nix entry in the registry, and the 2.6.0 tag doesn’t unambiguously refer to a commit, and there’s no attribute specified; so nix/2.6.0 expands to a ‘mutable’ flake:nix/2.6.1#defaultPackage.x86_64-linux, and an unambiguous flake reference like github:NixOS/nix/e044ccb67ce38d11059de32515306f5f1bd2f04f#defaultPackage.x86_64-linux.
I don’t quite understand why nix profile upgrade nix/2.6.0 doesn’t work as-is. I mean, the same user-friendly reference doesn’t expand as before; I think it has to be nix profile upgrade defaultPackage.x86_64-linux (or nix profile upgrade 14 or whatever).
It does make sense to me that nix profile upgrade fetches a newer revision from the same tag.
I like the idea of being able to update the tag version of the flake reference itself, if it makes sense for the flake reference.
I think automatically using a higher priority when installing would be a footgun.