Re: Parameterized packages

[Chris Marusich]

Mark H Weaver <address@hidden> 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.z’, 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.

I agree with Mark; using a custom package field seems better here
because the arguments change the derivation (don't they?), but
properties do not.  Maybe "argument-overrides"?

-- 
Chris

signature.asc
Description: PGP signature