Re: proposal: (define (find-guix-packages list-of-names) ... )

[Ludovic Courtès]

Florian Paul Schmidt <address@hidden> skribis:

> Hi, and thanks for your reply..
>
> On 11/15/2015 09:35 PM, Ludovic Courtès wrote:
>
>> I think ‘specification->package’ from (gnu packages) is the
>> procedure you want.  Like this:
>>
>> (map specification->package '("guile-2" "gnupg-2.0" "coreutils"))
>>
>> It emits a warning in case the specification is ambiguous.
>>
>> Maybe we could/should use it in the example GuixSD configurations,
>> and at least document it somewhere.
>>
>> WDYT?
>
> Sounds like a plan. Though in this use-case I think I'd prefer an
> error over a warning. For the simple reason that during system
> reconfigure a warning might be missed easily. Especially after a guix
> pull where suddenly a package spec might become ambiguous where it
> wasn't before and a different package gets chosen.
>
> OTOH, maybe that's overdoing it and even with the error instead of a
> warning there are still some failure modes somewhat similar to this:
> E.g. Package foo disappears while a quite different package foo
> appears (possibly in a different module). Quite unlikely but possible.

There’s a range of options here: referring to variables by name (this is
best, you get an error if you got the name wrong, etc.; downside is you
need to know what modules to import), using ‘specification->package’, or
using something like what you suggested initially.

I’m fine with documenting ‘specification->package’ as an alternate
option.  Its semantics are exactly the same as when referring to a
package by name on the command line (a warning if it’s ambiguous, not an
error), which seems reasonable.

Thoughts?

Ludo’.