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/