Re: Parameterized packages

[Mark H Weaver <mhw@netris.org>]

Hi,

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Ludovic Courtès wrote:
>> While thinking about <https://issues.guix.info/issue/35671> and
>> looking
>> for ways to allow users to install just the locales they need right
>> from
>> ‘guix package’, I realized that “parameterized packages” are a
>> low-hanging fruit
>
> Wow.  Unexpected turn…
>
> I'm still thinking about this, so all this is just me doing it out
> loud:
>
>>   (package
>>     (inherit glibc-utf8-locales)
>>     (properties `((locales . ("zh_CN.utf8")))))
>>
>> and tadaam! we have a parameterized package.
>>
>> There’s a couple of gotchas:
>>
>>   • We’d need to store more info in manifest entries so that
>>     transformation options are preserved upon ‘guix upgrade’.
>>
>>   • We might need to expose the package parameters somehow, so
>> that if
>>     one types ‘--with-argument=foobar=baz’, they get a correct
>> error
>>     message saying that “foobar” is not a known parameter.
>
> Interesting idea to piggy-back on the properties field, and it might
> save some code (at least initially), but I don't see the overlap here.
>
> None of the current properties (superseded, upstream-name, *-variant,
> cpe-name, hidden?) make much sense to expose in this way; they're
> semimmutable facts about the package.

Also, at present, the current 'properties' field can be changed without
changing the derivation, and I think that's quite useful.  It's nice to
be able to do things like increase the build timeouts on a core package,
for the sake of a slow architecture, without forcing rebuilds of
everything on top of that package on other architectures.

So, I would prefer to see a different package field used for this.

     Thanks,
       Mark