Mark H Weaver writes: >> Ludovic Courtès wrote: >>> While thinking about 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