From: Pierre Neidhardt <mail@ambrevar.xyz>
To: ison <ison@airmail.cc>, Mark H Weaver <mhw@netris.org>
Cc: guix-devel@gnu.org
Subject: Re: Parameterized packages
Date: Thu, 02 Jan 2020 20:23:01 +0100 [thread overview]
Message-ID: <87a7753boq.fsf@ambrevar.xyz> (raw)
In-Reply-To: <20190719202906.lbanx5puk7t6q4cr@cf0>
[-- Attachment #1: Type: text/plain, Size: 4525 bytes --]
Hi!
Bringing this topic back to life now that I'm starting working on this.
1. Everyone seems to agree that we need a dedicated field in the package
declaration.
For now, 3 names were proposed:
- parameters
- options
- argument-overrides
I find "argument-overrides" a bit too verbose :p
I'll go with "parameters" for now since it's the title of this thread.
2. As Tobias and Ison suggested, we need to centralize the declaration of
parameters, so that we can list them and centralize metadata like the
description & types. Any suggestion on how to implement this in practice?
Where do we store them? How?
3. From Ludo's comment:
> • We’d need to store more info in manifest entries so that
> transformation options are preserved upon ‘guix upgrade’.
> ...
> • We might want to make the CLI option less verbose too, but how?
We'd also need a way to specify the parameters in the manifest specs and from
command line.
Now we have "@" and ":" for versions and outputs respectively. What about
parentheses? E.g.
"foo@2.0(:locale fr_FR.UTF-8 :audio pulseaudio :gui X)"
I think a plist like above would be less verbose than an alist.
To apply parameters to the rest of the command line, we could also do:
guix install --with-parameters="(:locale ...)" package-foo package-bar
4. From Ludo's comment:
> • 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.
I think we should only display a warning so that we can emulate global USE
flags as Ison suggested.
5. Global parameter storage
When using "guix install" it can be convenient not to have to repeat the
parameter specification. So it'd be nice to store it somewhere. What about
a file in ~/.config/guix/parameters.scm with something like
(parameters
:locale fr_FR.UTF-8
:audio pulseaudio
...)
?
6. Leverage build systems to automate parameterization when possible.
Some build systems use well-known flags. For instance, for the
gnu-build-system if the user sets the parameter "(:audio pulseaudio)" we could
automatically pass --enable-pulseaudio to the "configure" flags, even
for packages that didn't specify their own well-known parameters.
It would be nice if build systems had a way to report if a flag is supported
or not. Any clue?
To implement this, we could do the following:
(define-parameter audio
"Some description"
(types ...)
(argument
(lambda (pkg)
(match (package-build-system pkg)
(gnu-build-system
(add-to-configure-flags "--enable-pulseaudio"))
(cmake-build-system
(...))))))
7. Dependency management.
Also known as the USE flag nightmare among Gentoo users...
This is where hell breaks loose! :p
The problem: the user wants to specify a parameter to use globally where it
applies, on all installed packages and all their inputs, recursively.
For instance, use guile-2.2.4 instead of guile for all guile libraries, or
use pulseaudio everywhere, including in dependencies that are not explicitly
installed to the user profile.
The obstacle: A package may require inputs with a specific parameter.
For instance, BAR depends on a FOO package built with ":audio
pulseaudio". What happens if the user seta ":audio alsa" globally
and installs BAR? BAR needs to specify explicitly that its FOO input
requires pulseaudio. Otherwise BAR would fail to build.
To specify that a package input depends on a specific parameter, we could
extend the syntax of the (inputs ...) and (native-inputs ...) fields like so:
(input
`(("foo" ,foo "(:audio pulseaudio)")))
A bigger problem is that the parameter compatibility issue is combinatorial:
"Which parameter combination does BAR support?" It's hard to know it in
advance. Any idea how to tackle this?
The easy way around this is to not propagate the global parameters by
default, but this seriously limits the usefulness of global parameters.
Maybe a better workaround would be to automatically fall back to the default
value of all parameters when a build fails.
Cheers!
--
Pierre Neidhardt
https://ambrevar.xyz/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
next prev parent reply other threads:[~2020-01-02 19:23 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-14 11:54 Parameterized packages Ludovic Courtès
2019-05-14 15:17 ` Tobias Geerinckx-Rice
2019-05-17 14:23 ` Pierre Neidhardt
2019-05-17 18:15 ` Mark H Weaver
2019-07-19 5:41 ` Chris Marusich
2019-07-19 20:29 ` ison
2020-01-02 19:23 ` Pierre Neidhardt [this message]
2020-01-09 11:10 ` Pierre Neidhardt
2020-01-09 23:13 ` Marius Bakke
2020-01-10 12:29 ` Pierre Neidhardt
2020-01-10 16:19 ` Ludovic Courtès
2020-01-11 11:31 ` Pierre Neidhardt
2020-01-14 15:05 ` zimoun
2020-01-15 9:40 ` Pierre Neidhardt
2020-01-15 11:30 ` zimoun
2020-01-15 11:51 ` Pierre Neidhardt
2020-01-15 13:54 ` zimoun
2020-01-16 19:06 ` ison
2020-01-16 20:55 ` Ricardo Wurmus
2020-01-17 16:34 ` Pierre Neidhardt
2020-01-17 9:15 ` L p R n d n
2020-01-17 16:46 ` Pierre Neidhardt
2020-01-17 15:53 ` zimoun
2020-01-17 16:56 ` Pierre Neidhardt
2020-01-20 14:34 ` zimoun
2020-01-21 10:56 ` Build systems and implicit inputs Ludovic Courtès
2020-01-21 12:24 ` zimoun
2020-01-21 13:07 ` Pierre Neidhardt
2020-01-21 18:02 ` zimoun
2020-01-19 20:34 ` Parameterized packages Ludovic Courtès
2020-01-20 9:08 ` Pierre Neidhardt
2020-01-20 14:50 ` zimoun
2020-01-20 18:57 ` Pierre Neidhardt
2020-01-20 19:07 ` Pierre Neidhardt
2020-01-20 22:57 ` ison
2020-01-21 10:09 ` Pierre Neidhardt
2020-01-21 10:49 ` Ludovic Courtès
2020-01-21 12:15 ` zimoun
2020-01-21 13:13 ` Pierre Neidhardt
2020-01-21 19:04 ` zimoun
2020-01-22 9:54 ` Pierre Neidhardt
2020-01-22 12:23 ` zimoun
2020-01-24 21:56 ` ison
2020-01-26 19:35 ` zimoun
2020-01-27 10:13 ` Pierre Neidhardt
2020-01-27 11:23 ` zimoun
2020-01-27 11:50 ` Pierre Neidhardt
2020-01-27 12:34 ` zimoun
2020-01-27 10:04 ` Pierre Neidhardt
2020-01-25 18:52 ` John Soo
2020-01-27 10:17 ` Pierre Neidhardt
2020-01-20 14:12 ` zimoun
2020-01-17 16:31 ` Pierre Neidhardt
[not found] ` <875zhbvzfz.fsf@guixSD.i-did-not-set--mail-host-address--so-tickle-me>
2020-01-17 16:41 ` Pierre Neidhardt
2020-01-19 20:30 ` Ludovic Courtès
2020-01-15 11:43 ` Pierre Neidhardt
2020-01-15 11:44 ` Pierre Neidhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a7753boq.fsf@ambrevar.xyz \
--to=mail@ambrevar.xyz \
--cc=guix-devel@gnu.org \
--cc=ison@airmail.cc \
--cc=mhw@netris.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.