doc: don't recommend listing packages with nix-env

[fricklerhandwerk]

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[sternenseemann]

This just seems silly to me. There's nothing wrong with using nix-env in this way and the presented alternative is strictly worse?

[fricklerhandwerk]

Do we want to get people away from nix-env or not? I thought it was widely agreed-upon that using nix-env should not be encouraged, and that the only stable, reliable, and (mostly) sane interface to Nix is the Nix language.

[Atemu]

Listing packages given a (possibly nested) attrset while ignoring any eval errors is one of the only sensible uses of nix-env. What we want to get away from is using nix-env for imperative package management because it really sucks quite a lot at that.

[fricklerhandwerk]

@Atemu would I be missing something crucial if I claim this can be done in the 4-liner I added as an example?

[Atemu]

Yes, it'd fall on its nose on the first attribute that doesn't eval or doesn't have a version. haskellPackages is quite well behaved in this regard but go I dare you to this on pkgs... The only way to get this sort of information reliably on pkgs is nix-env; I've been there.

[fricklerhandwerk]

Incredible... just ignore assertions?

https://github.com/NixOS/nix/blob/master/src/nix-env/nix-env.cc#L195
https://github.com/NixOS/nix/blob/master/src/libexpr/get-drvs.cc#L311-L330

How about we all forget that code ever existed, merge this PR, and focus on something else?

[Atemu]

I don't have a strong opinion on this and I don't maintain this part of Nixpkgs. I also don't have anything more to contribute to this discussion, so I'm going to unsubscribe here.

[fricklerhandwerk]

@maralorn @ncfavier opinions?

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2024-06-03-documentation-team-meeting-notes-131/46810/1

[maralorn]

I have no strong opinion on this and I frankly don’t feel like arbitrating this on my free time. So I will just leave some thoughts:

I empathize with the desire to get rid of references to nix-env. I mean in general even mentioning that packages won’t get listed by nix-env -qa seems quite irrelevant because that workflow seems rather alien to me. I wonder if anyone ever actually needs this on the command line.

On the other hand the fact that this command becomes so much more complicated without it is annoying, eval errors will slip in from time to time and this usage of nix-env seems harmless in contrast to the usual critique of that command.

I think the biggest advantage of having the listing in the manual is that it makes the package set a bit more graspable.

My usual workflow is search.nixos.org or nix repl + tabcompletion, I don‘t know if that’s representative but if it is it might be the way to go also for the manual …

[sternenseemann]

Incredible... just ignore assertions?

You fundamentally have to do this when dealing with how nixpkgs works. haskellPackages is a very tame corner of nixpkgs, but even here you'll need to deal with assertions if you want to know outPaths.

the only stable, reliable, and (mostly) sane interface to Nix is the Nix language.

It's frankly bizarre to state that to list packages you should

1. Install jq,
2. Copy and paste some code snippet that is specific to haskellPackages

instead of using a subcommand of nix-env(1) that is not problematic.

I thought it was widely agreed-upon that using nix-env should not be encouraged

Yes, nix-env for package management is to be discouraged, but that concerns nix-env -u and nix-env -i. I just don't see any alternative to nix-env -qP in this case.

[maralorn]

I like this in general.

I still think that having a few example packages listed in the Haskell section makes it easier to quickly grasp the structure of the package sets in question. But overall this change is already an improvement.

[fricklerhandwerk]

@maralorn I'd prefer to generate these examples automatically. For instance, we could list all compilers, and show a small subset of packages. As noted in the commit message, we have precedence with Python. It just needs time to sit down and get it into shape.