Why isn’t nixpkgs.darwin.trash found using a nix-env query?

If I launch nix repl I can verify that I have:

nix-repl> (import <nixpkgs> { }).darwin.trash.name
"trash-0.9.2"

But if I try to find it with nix-env I get this:

% nix-env -qaP --description trash
error: selector 'trash' matches no derivations

I see that the trash derivation is created using darwin.callPackage but it still produces a regular derivation with a name attribute.

Can someone explain why the trash derivation is different? And should this issue be addressed?

I found the answer: nix-env only searches attribute sets with recurseForDerivations set to true, which is not the case for the darwin attribute set.

Makes me wonder if either the trash derivation should be moved out of the darwin attribute set, or the attribute set should be created with recurseIntoAttrs.

And for the records, the contents of the attribute set can be shown using nix-env like this:

nix-env -qaPA nixpkgs.darwin --description

A lot of stuff in darwin is support for building packages on Darwin, not things you’d want to install independently. If we want to have a set of darwin-only packages intended for end-user consumption, I’d recommend adding a new top-level darwinPackages (similar to linuxPackages) that’s set to recurseIntoAttrs. I don’t know how many things would actually go into this though, we could also just call it nixpkgs.darwin-trash.

There are only four items in the linuxPackages attribute set, although there are more than two dozen different variations of this attribute set.

For a darwinPackages attribute set I think these items are obvious candidates:

nixpkgs.osxfuse
nixpkgs.macvim
nixpkgs.darwin.trash
nixpkgs.wxmac
nixpkgs.pinentry_mac

I’m a little hesitant about the last one because there are several pinentry implementations, so it might seem inconsistent to move one of them to a different attribute set, but on the other hand, it is a macOS application (.app) that can only be installed on macOS.

Less sure about this stuff, although it does list darwin as platform requirement:

nixpkgs.gtk-mac-bundler
nixpkgs.gtk-mac-integration
nixpkgs.gtk-mac-integration-gtk2

nixpkgs.qt5.qtmacextras
nixpkgs.qt512.qtmacextras
nixpkgs.qt59.qtmacextras

And then there is this, but it seems auto-generated, is already in its own attribute set, and I think it exists only for nix-shell:

nixpkgs.rubyPackages_2_4.osx_keychain
nixpkgs.rubyPackages_2_5.osx_keychain
nixpkgs.rubyPackages_2_6.osx_keychain

Should we prepare a PR for putting the first five packages into its own attribute set?

I do think it would be nice to query mac-specific packages, hence why I would suggest doing this instead of moving trash to the root attribute set.

Doing a search for mac stuff is difficult because things can be named osx, mac, darwin, or neither.

As for name, perhaps macPackages would be better than darwinPackages? After all, macvim, pinentry_mac, and wxmac require the window manager.

1 Like

Moving these 5 packages into its own set seems like a good idea to me, though we’ll have to leave aliases behind.

I never really thought about darwin vs mac being to do with the presence of a window manager, but I guess that makes sense. I was thinking darwinPackages simply because Nix uses darwin as the platform name, but given the GUI apps, I’d suggest macosPackages (rather than macPackages because the OS is called “macOS”).