Re: Parameterized packages

["Ludovic Courtès" <ludo@gnu.org>]

Hello!

The way I see it, we’re still toying with the idea and its pros and
cons—discussions about CLI syntax can come later.  ;-)

The added flexibility of package parameters is definitely nice, but
really, maintainability is a big concern.  The example Tobias gave (a
parameter to enable/disable X11 support) is interesting because it shows
that parameters can quickly become ubiquitous and get “out of control”,
from a maintenance viewpoint.

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> 7. Dependency management.
>    Also known as the USE flag nightmare among Gentoo users...
>    This is where hell breaks loose! :p
>
>    The problem: the user wants to specify a parameter to use globally where it
>    applies, on all installed packages and all their inputs, recursively.
>
>    For instance, use guile-2.2.4 instead of guile for all guile libraries, or
>    use pulseaudio everywhere, including in dependencies that are not explicitly
>    installed to the user profile.
>
>    The obstacle: A package may require inputs with a specific parameter.
>    For instance, BAR depends on a FOO package built with ":audio
>    pulseaudio".  What happens if the user seta ":audio alsa" globally
>    and installs BAR?  BAR needs to specify explicitly that its FOO input
>    requires pulseaudio.  Otherwise BAR would fail to build.
>
>    To specify that a package input depends on a specific parameter, we could
>    extend the syntax of the (inputs ...) and (native-inputs ...) fields like so:
>
>    (input
>     `(("foo" ,foo "(:audio pulseaudio)")))
>
>    A bigger problem is that the parameter compatibility issue is combinatorial:
>    "Which parameter combination does BAR support?"  It's hard to know it in
>    advance.  Any idea how to tackle this?

That’s another good example of a problem that would arise.  :-/
It doesn’t seem reasonable to me to add complex logic in (guix packages)
to deal with this issue; I would very much prefer to leave input
handling unchanged.

I’m worried about the maintenance cost of parameters.  Having the
feature is one thing, but being able to guarantee that the package
combinations we offer all work is another one.

We could have the feature and use it very seldom in Guix itself, but I’m
guessing that that’s not what you have in mind.

Also, for CI purposes, we would need a way to enumerate all the possible
combinations…

Apologies for spoiling the party :-), but I think these concerns need
all our attention!

Thanks,
Ludo’.