GNU bug report logs - #54221
[PATCH 0/4] vim: Detect plugins via search paths.

Previous Next

Full log

View this message in rfc822 format

From: Maxime Devos <maximedevos <at> telenet.be>
To: SeerLite <seerlite <at> nixnet.email>, 54221 <at> debbugs.gnu.org
Subject: [bug#54221] [PATCH 3/4] gnu: vim: Update package style.
Date: Thu, 03 Mar 2022 18:46:33 +0100

[Message part 1 (text/plain, inline)]

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.

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.