SeerLite schreef op do 03-03-2022 om 13:49 [-0300]:
> The blog post that introduces label-less inputs also introduces 
> 'search-input-file', which made me think they were both part of the 
> "package definition modernization process".

The problem with 'which' was that it looks in 'native-inputs' (+ inputs
when compiling natively), even when we need 'inputs'.  To fix this,
adding an 'inputs/native-inputs' argument was proposed
(https://issues.guix.gnu.org/47869).  That interface was considered
a bit weird, so then (string-append (assoc-ref ...) "bin/...") was
proposed.  That's rather verbose though, so 'search-input-file' was
introduced.

In short, 'search-input-file' was introduced to help with locating
binaries from 'inputs' (at least from my POV, shortly after ludo began
using 'search-input-file' for delabelification).

For looking in native-inputs (compilation tools etc.), I would prefer
'which' above the 'search-input-file' because it's a lot more concise,
though I suppose there is an argument to be made for using 'search-
input-file' for consistency.

There's the downside of not raising an exception in case the file is
not found though.  However, there appears to be very few code that
actually relies on the 'return #f' behaviour (search for
'(or (which' and '(if (which'), so I think the behaviour can
be changed without much trouble (on 'core-updates').

Greetings,
Maxime.