Florian Paul Schmidt <mista.ta...@gmx.net> 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’.