maintenance/doc/guix-days-2020/parameterized-packages-guix-days.org

* Parameterized Packages
** Definititions
*** USE flags
The inspiration for Parameterized Packages in Guix largely comes from
Gentoo Linux, which is well known for its powerful [[https://wiki.gentoo.org/wiki/USE_flag][USE flags]], which
allow the end user to customize various properties of the package
build process.  Common USE flags include *X*, for enabling X11 support,
*dbus* to toggle dbus integration, and *debug* to enable debugging
support.

A key feature of USE flags is that they can be enabled recursively for
every installed package that supports them, allowing extensive system
configuration to be enabled with just a few USE flag declarations.
*** Composition
Another powerful feature of package parameters is the ability to
compose multiple paramaters together, allowing packages to describe
custom behaviors for arbitrary combinations of parameters. The full
list of supported parameters are passed in as an argument to the
package record, allowing package writers to write custom behaviors for
any combination of parameters.

** Integration with Functional Builds
A common problem with Gentoo USE flags occurs when packages in a user
profile themselves depend the same package, only with conflicting USE
flags set.  Fortunately, Guix's functional package builds allow us to
have multiple versions of a package in the store that differ only in
the parameter set.
*** Hackability / customizability
An easy interface for package customization would further Guix's goal
of being a hackable package manager.
** Disadvantages
*** Complexity
The flipside of increased expressiveness in package definitions is
increased complexity. As the number of parameters grows, there is a
explosion in the number of possible parameter combinations. This means
that Guix may be unable to test all possibile parameter combinations
available to the end user.
*** Readability
To apply a parameter to a package definition, we need a bunch of ~(if
flag-is-set ...)~.  This can make the package definitions significantly more
cumboersome to read.  Helper macros or functions could help to some extent.
*** Substitutes
When a user customizes their package parameters, they are creating a
distinct version of the package that will have a unique store
hash.  Therefore unless Guix dedicates resources to building
substitutes for common package parameters, they will have to compile
everything themselves.
** Questions / Discussions
*** Dealing with propagation
We agreed that we want to to develop an alternative approach to the
Gentoo USE flag system.  Guix packages should be able to declare which
parameters that they understand, and in addition we believe that guix
packages should explicitly declare which parameters are allowed to
propagate to any dependencies of the package.  If a parameter is not
allowed to propagate, then when the dependencies are evaluated, they
will not see that the parameter has been set, instead falling back to
the parameter default.  In addition, packages will not be able to set
any additional parameters for their dependencies that the user has not
already declared.
*** Technical considerations
**** Host instead of build side
Because we want to support parameters that can add additional
dependencies to the package, the parameter handling logic needs to
occur on the host side.  One possibility suggested was for the
parameters to be evaluated when the package is lowered into a bag.