guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Parameterized packages


From: Tobias Geerinckx-Rice
Subject: Re: Parameterized packages
Date: Tue, 14 May 2019 17:17:38 +0200

Ludo',

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.

While a dedicated field can provide richer metadata, such as description, basic ‘types’ & sane/permitted values, to be used by the UI.

Looking at Exherbo/ntoo, this will inevitably lead to factoring out very common option metadata so one doesn't have to keep writing ‘x11 bool "Add support for the X Window System"’ in every. single. package.

Then come the people asking how to set CFLAGS for all packages and you'll know you've made it.

• We might want to make the CLI option less verbose too, but how?

Possibly relevant: do you see package options¹ being added to package specifications? That seems to be the classical approach.

Kind regards,

T G-R

[1]: I use the term ‘option’ because it's what my last FHS distribution called them, and it was a good distribution, and because ‘arguments’ is already an unrelated field in package expressions, and flags are boolean, but substitute whatever name you prefer.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]