Hi Ludo!

Ludovic Courtès <ludo@gnu.org> writes:

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

Sure thing!

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

What I understood from Tobias comment on the X11 support parameter is
that we need to store the parameter metadata centrally.  Why do you
think this suggests it will get "out of control"?


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

Indeed, the ultimate goal would be to do things like "install a headless
system" and "use static libraries everywhere", etc.

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

Considering the number of outputs would explode as parameters get added,
it does not seem reasonable to try building everything.  Maybe an easy
option would be:

- Only build the default packages (i.e. using the default values of the
  parameters).
- If a non-default output is requested often enough (to be defined) then
  build it.

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