[bug#57704] [PATCH v3] guix: Filter unspecified inputs when sanitizing.

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2185 bytes --]

> 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

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]