3.3 KiB
Parameterized Packages
Definititions
USE flags
The inspiration for Parameterized Packages in Guix largely comes from Gentoo Linux, which is well known for its powerful 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.