A rg 'outputBin = "dev' detects 45 unique nix files, including pkgs/development/libraries/gtk/4.x.nix.

I agree that the eval overhead is not pretty. Would you prefer we switch to pkg.${pkg.outputBin} or pkg.bin or ... chains to avoid all the list allocations, or would you prefer we passthru the dev output as bin in each package instead?

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 410779

x86_64-linux

This works fine:

nix-repl> :b stdenv.mkDerivation { name = "test"; stictDeps = true; buildInputs = [ sdl2-compat ]; dontUnpack = true; configurePhase = "sdl2-config --help"; }     
...
       > Usage: /nix/store/3r1cplqpqfxc3j3my2ma0l311rs932qy-sdl2-compat-2.32.54-dev/bin/sdl2-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--cflags] [--libs]
...

What's the use case for getBin?

If convenience for the getExe use case is the goal (a narrow goal, but alas), it'd be hard to beat passthru.exe = "${getDev finalAttrs.finalPackage}/bin/sdl2-config";.

That could then even be made compatible with getExe using the lib part of https://github.com/NixOS/nixpkgs/pull/173675/files

• lib/attrsets: make getBin and co respect outputBin if set
• sdl2-compat: set meta.mainProgram

I dropped the two commits named above, but kept the rest since the fixes along the way still apply. I'll open a treewide pr for the alternative approach

refs for posterity:

• 990861d
• 4630d5d

This works fine:

nix-repl> :b stdenv.mkDerivation { name = "test"; stictDeps = true; buildInputs = [ sdl2-compat ]; dontUnpack = true; configurePhase = "sdl2-config --help"; }     
...
       > Usage: /nix/store/3r1cplqpqfxc3j3my2ma0l311rs932qy-sdl2-compat-2.32.54-dev/bin/sdl2-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--cflags] [--libs]
...

What's the use case for getBin?

It does not work if strictDeps is spelled correctly.

It does not work if strictDeps is spelled correctly.

🤦
Wish I could finish those mkDerivation refactors yesterday, but we're ways away from having a checked variant of it.

nativeBuildInputs works, but that would get the wrong splice.
I suppose dev should use input propagation to add itself as a native build input? @Ericson2314

is this amputated PR mergeable or is there reason to maybe want to reintroduce the dropped commits?

Yeah it's close.

The lib.getFirstOutput commit should come with a test case and a documentation update.
Normally we/lib maintainers would recommend a separate PR for lib changes, but the other commits aren't any more urgent so it may be ok to keep it here.
(Unfortunately getFirstOutput has no direct tests, so we're overdue for creating some. Can be added to lib/tests/misc.nix)

The buildRustCrate commit seems fine, but a little explanation in the commit message would be good for other maintainers to understand the change.

The outputInclude docs look ok to me.