Re: Parameterized packages

[Pierre Neidhardt <mail@ambrevar.xyz>]

[-- Attachment #1: Type: text/plain, Size: 3400 bytes --]

zimoun <zimon.toutoune@gmail.com> writes:

> Maybe I misread something and/or I misunderstand other thing but the
> symbols 'video-player' and 'python' need to be defined somewhere. And
> with this proposal adding the field 'parameters', this somewhere is
> outside the package. Therefore, I will end up to a big mess, IMHO.

I think you misread indeed :p

> Let consider the packages 'foo' and 'bar'. They depend both on say the
> 'video-player' package.

No, there is no video-player package.  It's a "package parameter".

> Well, the definition looks like:
>
> --8<---------------cut here---------------start------------->8---
> (package
>  (name "foo")
>  (...)
>  (parameters video-player)
>  (...))
>
> (package
>  (name "bar")
>  (...)
>  (parameters video-player)
>  (...))
> --8<---------------cut here---------------end--------------->8---
>
> Now, the user wants to install the both packages but:
>  -  they requires that "foo" depends on vlc without any X support, say
> "vlc-no-x"
>  -  and they require that "bar" depends on full "vlc"
>
> So how to do?
> Where is defined 'video-player'?

I think there is a misunderstanding on the definition of "package
parameters".

I intend to make package parameters first class objects for the reason
Ison explained in the previous message.

To answer your previous example, you'd do something like this, with a
made-up syntax:

guix install "foo(:video-player vlc-no-x)" "bar(:video-player vlc)"


>> I'm not sure with the function method how easy it would be to inform the
>> user of all available options. For example when running `guix search`
>> would it be able to programmatically collect all the options that a
>> package has and display them there?
>
> To me, the "official" packages in master should stay "simple" with no
> parameter. Otherwise, it is will hard -- if not impossible -- to
> ensure that all combinations work; or the number of parameters will be
> very limited.

Guix (unlike Gentoo) is functional, so that good news is that we can
have multiple versions of the same packages in the store.  This
essentially fixes the clash issues with Gentoo.

>> Also it seems that whether or not there are global meta objects is a
>> separate issue than whether to use parameters or functions. It looks like
>> either method could use them or not. In the function approach you could
>> still just pass in an alist as above.
>
> Yes.
> But the big differences are:
>
>  1. the base package is untouched
>  2. the arguments are locally defined
>  3. everything is explicit
>
> So less surprises IMHO.

But you can't compose the parameters, so this ruins the main point of
package parameters.

> Well, I really do not know and I do not have a strong opinion: I just
> fear that the 'parameters' field would add complexity which would lead
> to unmaintenable packages.

As you said, I think it would simply add more "tunable" options to
packages, that's it.  The main burden for packages is to make sure all
tunables of a package work together, but there is no escape to this.
Nix / Gentoo have the same problem here.

And well, if some parameter combination does not work, it's not the end
of the world either, the user would not have this specific version of a
package with present Guix either.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]