[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#57704] [PATCH v3] guix: Filter unspecified inputs when sanitizing.
From: |
Maxime Devos |
Subject: |
[bug#57704] [PATCH v3] guix: Filter unspecified inputs when sanitizing. |
Date: |
Sat, 10 Sep 2022 12:19:32 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 |
Am Samstag, dem 10.09.2022 um 02:33 +0200 schrieb Maxime Devos:
The docstring is nice, but with documentation, I meant the manual,
presumably in ‘(guix)package Reference’, maybe also in the packaging
tutorial in the cookbook.
I don't see the current practice documented, so I think we're actually
good on this front.
That sounds bad to me -- the undocumented surface should be decreased,
not increased. Also, it is actually documented a little:
‘inputs’ (default: ‘'()’)
‘native-inputs’ (default: ‘'()’)
‘propagated-inputs’ (default: ‘'()’)
These fields list dependencies of the package. Each element
of these lists is either a package, origin, or other
“file-like object” (*note G-Expressions::); [...]
#false (or, in this case, *unspecified*) is neither a package, origin or
other file-like object. Maybe you can add that #false is also allowed
but ignored?
On 10-09-2022 09:41, Liliana Marie Prikler wrote:
inputs)
- (else (map add-input-label inputs))))
+ (else (filter-map (lambda (input)
+ (if (unspecified? input) #f
+ (add-input-label input)))
+ inputs))))
(when cond ...) / (unless cond ...) returning *unspecified* when (not
cond)/cond is an implementation detail:
* The return values(s) when (not cond)/cond is not documented in
(guile)Conditionals
* maybe: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56799#17
There is an interest in letting it return zero values instead of
*unspecified*, see e.g.
https://scheme-reports.scheme-reports.narkive.com/QSQtJSAh/unspecified-values
and a ‘bug’ on bugs.gnu.org I cannot find anymore about actually
doing this change.
By assuming that when/unless returns *unspecified* here, an
additional backwards-compatibility concern is introduced.
As such, I don't think relying on this to be a good idea.
Alternative proposal: instead of (when cond package), maybe
(and cond package)?
Greetings,
Maxime
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature