GNU bug report logs - #49597
[PATCH core-updates 00/15] Ajust packages to label-less input style

Previous Next

Package: guix-patches;

Reported by: Ludovic Courtès <ludo <at> gnu.org>

Date: Fri, 16 Jul 2021 15:51:02 UTC

Severity: normal

Tags: patch

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #68 received at 49597 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 49597 <at> debbugs.gnu.org
Subject: Re: bug#49597: [PATCH core-updates 00/15] Ajust packages to
 label-less input style
Date: Mon, 19 Jul 2021 18:47:54 +0200
[Message part 1 (text/plain, inline)]
Ludovic Courtès schreef op ma 19-07-2021 om 16:50 [+0200]:
> [...]
> 
> > In the example you gave, both search-input-file and the original 'string-append'
> > and 'assoc-ref' look convenient to me, though the latter more so than the other,
> > and a third variant could be
> > 
> >   #$(file-append (this-package-native-input "openmpi") "/lib/libmpi.so")
> > 
> > which avoids 'string-append' and 'assoc-ref'.
> 
> Yes, but you’re still relying on the name, “openmpi”.
> 
> If I do:
> 
>   (package
>     (inherit thing)
>     (inputs `(("mpich" ,mpich)
>               ,@(delete "openmpi" (package-inputs thing)))))
> 
> … then you have a problem: ‘this-package-input’ won’t find “openmpi”.
> It’s a real, common use case.  That’s why we need to be careful about
> the idioms we promote.
> 
> WDYT?

Then you could do:

  (package
     (inherit thing)
     (inputs `(("openmpi" ,mpich) ; use "openmpi" label
               ,@(delete "openmpi" (package-inputs thing)))))

or just use "mpi" in the original and new package as input label,
but that doesn't mesh well with eventually removing input labels.

Myself, I don't mind input labels much. They look like arguments to
a procedure to me, albeit with an unusual syntax for referring to
them.

> > (I prefer explicitely writing in the package definition in which input a file
> > will be found, as a kind of documentation, though in this case it probably
> > doesn't really matter.)
> 
> Yeah, I like that too.  OTOH, ‘search-input-file’ has the advantage that
> it errors out if the file is not found, whereas
> 
>   (string-append (assoc-ref inputs "foo") "bar")
> 
> always “works” and problems occur possibly much later, at run time.

I'd suggest using #+/#$(file-append (this-package-[native]-input "foo") "/bar"
instead of (string-append (assoc-ref ...) ...).

I think I have a method for explicitely choosing which input to use,
using package names instead of labels, that still works nicely with
"--with-input":

(define* (lookup-libmpi-library package)
  ;; open-coding could be avoided by adding a 'is-mpi-library?'
  ;; package property and using that instead of hard-coding a list
  ;; of package names 
  (file-append (or (lookup-package-input package "openmpi")
                   (lookup-package-input package "mpich")
                   ...)
               "/lib/libmpi.so"))

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

This bug report was last modified 3 years and 300 days ago.

Previous Next


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