imperative package management is not part of the core idea of nix. nix-env still has a niche for managing channels on flakeless systems.
for users that want imperative package management, there are plenty of better options created by the community, such as flakey-profile and my own nix-inst.
the nature of nix makes it very easy to make an imperative frontend for it. i don’t think we need to enshrine one option above the others, especially not one as cumbersome as nix profile.
this depreciation would just serve as a warning for now, nix profile will still be supported, but at some point in the future it might not be.
1 Like
A counterpoint to this would be that imperative installation is often a good starting point for newcomers who want to try nix or want access to the large package collection but do not want to learn how to set up NixOS, Nix Darwin, Home Manager, etc. Being able to pick up Nix as a replacement for Homebrew makes it far more approachable and useful for more people.
4 Likes
yes, i’m well aware of the advantages of imperative package management. that’s why i wrote nix-inst. my point is that nix profile is not very intuitive, and new users would be better off with with a different imperative entry point. (flakey-profile has the advantage that you can smoothly transition to a declarative system at any time, and it can be transferred to any system, i’m working on adding this capability to nix-inst, but its quite difficult when nix-inst has the goal of not relying on flakes.)
1 Like
I kinda disagree. We should improve the ergonomics of nix shell so newcomers can use the packages, but there’s a lot of weirdness in nix profile in keeping track of what you installed.
Would it not then be preferable to exhaustively identify said weirdness and address it?
6 Likes
i would be interested in this as well. i’ve had some issues myself for example, but i feel many have been fixed by `nix profile`: Allow referring to elements by human-readable name by iFreilicht · Pull Request #8678 · NixOS/nix · GitHub alone (something many may have not experienced yet as it was released with nix 2.20, but nixpkgs still defaults to 2.18 iirc)
“better options” is pretty subjective. in the case of flakey-profile, it is described as
Declarative profiles with nix flakes
…this isn’t an alternative to nix profile. the entire point of nix profile is to be imperative
and taking a look at nix-inst’s readme, i really don’t see many advantages here. the syntax is extremely similar to nix profile in the first place, with the manual --flake, --file, or --expr. i would also say the “heuristics” are kinda a footgun in of itself. what if there’s a flake in my registry with the same name as a package? these things should be explicit
regardless of these small criticisms though, i don’t see how any of these really justifies deprecating nix profile as a whole. imperative package management is very important to a lot of newcomers, and i would much rather see that experience improved on (like with possible improvements from the other projects mentioned) rather than removed
2 Likes
and taking a look at nix-inst’s readme, i really don’t see many advantages here. the syntax is extremely similar to nix profile in the first place, with the manual --flake, --file, or --expr.
there’s a 9 point list of advantages, nix-inst can do a lot of things that nix profile simply can’t, such as updating non-flake packages.
i would also say the “heuristics” are kinda a footgun in of itself. what if there’s a flake in my registry with the same name as a package? these things should be explicit
an installable with no special characters in its name will always default to a package from <nixpkgs>. the heuristics used do not depend on the state of the system, the same string will always be interpreted in the same way. additionally, these are only used when installing packages, after that point the update expression will be used. use --flake if you want to refer to a flake from the registry.
regardless of these small criticisms though, i don’t see how any of these really justifies deprecating nix profile as a whole. imperative package management is very important to a lot of newcomers, and i would much rather see that experience improved on (like with possible improvements from the other projects mentioned) rather than removed
nix profile has a number of serious bugs, and the situation with CppNix means that, for the vast majority of users, there’s basically no hope these will actually be fixed.
the entire point of nix-inst is to improve that experience. moving the imperative frontend out of the nix core allows a faster development cycled, allowing bugs to be fixed faster.