lib.getExe best practices discussion thread

Development
1

Hi all, I would like for us to start a discussion on this PR. I got a feeling that it’s going to be a little controversial thus I am creating a separate thread for this

CC: @roberth @Infinisil @Sandro

1 Like
2

In the discussion of the alternatives "${lib.getBin pkgs.something}/bin/something should be "${lib.getBin pkgs.something}/something, right?

regarding the name: how about “deriveExe”?

But tbh, I’m not happy with having to very similar functions in the lib. There will be countless “why are there functions? which to use?”-discussions in the future.

Can we have mkDerivation populate meta.mainProgram from pname/name as default?

1 Like
3

lib.getBin gets bin derivation output if it is available, not bin folder

But tbh, I’m not happy with having to very similar functions in the lib. There will be countless “why are there functions? which to use?”-discussions in the future.

We are on the same page, I would prefer revert of previous patch at least until meta.mainProgram is defined everywhere

Can we have mkDerivation populate meta.mainProgram from pname/name as default?

We can but at that point revert of lib.getExe would be more appropriate solution

I was working on alternative implementation and found out this: lib: add lib.getExe' function by gytis-ivaskevicius · Pull Request #247115 · NixOS/nixpkgs · GitHub At this point I am not sure whats the point of lib.getBin

4

See some discussions in stdenv.mkDerivation: default meta.mainProgram to pname by figsoda · Pull Request #142474 · NixOS/nixpkgs · GitHub, at the time lib.getExe was not a thing yet and it was only about nix run, but similar arguments could be made for lib.getExe as well

5

Can we have mkDerivation populate meta.mainProgram from pname/name as default?

This deteriorates data quality and therefore deteriorates error messages.
If we want to have a reputation of having unreliable tooling, making guesses in the library is a good way to do it.

nix run is a bit different for two reasons:

It’s less likely to be used in generic code that passes an arbitrary parameter to nix run.

nix run can inspect the bin directory and print an informative error message when the assumption doesn’t hold, whereas getExe can not inspect the bin directory, which causes the error to be deferred to a different place and time, further removed from the cause, and having less context is available when it occurs.

2 Likes
6

I am more than happy to have this change as long as it does not require removing lib.getExe and few months later adding it back in

Is anyone working on adding meta.mainProgram to packages?

I upgraded nixpkgs to master and got 6 warnings of lib.getExe being used, lib.getExe in this evaluation was used 7 times. Somehow I got a feeling that this is going to be the same warning ratio in other projects of mine

1 Like
7

Is anyone working on adding meta.mainProgram to packages?

https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+mainProgram+

8

Yep, I did exactly the same search and noted it in one of my Github comments. It is just a couple of packages, I am not sure if this is a work in progress or that’s it

9

I get your point, but of course mkDerivation should only populate mainProgram if $out/bin/$pname does exist.

Edit: …which may be hard because the attribute is generated before the derivation is realized, right?

10

It is impossible without import-from-derivation, which is disallowed in nixpkgs, which is why I suggested having ofborg check for this:
https://github.com/NixOS/nixpkgs/pull/246386#issuecomment-1664164847

There has been quite a few treewide pull requests for this in the past few hours, looks like the required treewide changes are being completed at a pretty fast pace.

1 Like