Re: Parameterized packages

[zimoun <zimon.toutoune@gmail.com>]

Hi,

On Fri, 24 Jan 2020 at 23:06, ison <ison@airmail.cc> wrote:

> My understanding of the global definitions they're talking about is that
> they would just be meta objects, not global preferences.
> For example (maybe it won't look like this, but just a guess):
> Instead of passing the arguments "mpv" and "3.7" into your function you'd
> give the parameters:
> '((video-player . "mpv")
>   (python-version . "3.7"))
> to the package.
> video-player and python-version would be globally defined meta objects
> that just give descriptions about what these parameters should be used for
> and such (so users can read more information about package parameters when
> looking up packages). But the actual values that get used by the package
> are not global, they're passed into the package just like your function
> example.

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.

Let consider the packages 'foo' and 'bar'. They depend both on say the
'video-player' package.
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'?
How to install the both packages with the same transaction?


> 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.

However, Guix should provide more tune-able rewriting package
functions. And these modified packages should live in channels;
possibly official ones to be built by Berlin (substitutes).


> 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.


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.


All the best,
simon