Re: Parameterized packages

[ison <ison@airmail.cc>]

On Wed, Jan 15, 2020 at 02:54:25PM +0100, zimoun wrote:
> Everything is doable with Guix. ;-)
> However, it is not clear to me what is the best/easiest way to go.
> For example, here [2] I give a try.
> 
> [2] https://lists.gnu.org/archive/html/help-guix/2020-01/msg00087.html
> 
> 
> And what I was thinking is a mechanism to easily set some arguments to
> the build-system; for example changing the compiler toolchain (say
> replacing GCC by Clang/LLVM).
> 
> Well, as I said, I do not know if it is related to "parametrized
> packages" because I am not sure to understand the final aim for these
> "parametrized packages". :-)

Maybe the current discussion is trying too hard to emulate Gentoo's USE
flags and dependency graph concept (perhaps its my fault for bringing up
global flags). But that feels like introducing "side effects", and maybe the
whole idea should be treated more "functionally" in Guix.

That is, simplify the problem to the mere concept of passing arguments to
functions and nothing more. Take the headless server example: some parameter
is passed to a package such as
'("-X")
That package would then be entirely responsible for what to do with them. If
the package decides not to pass the same parameters to its inputs then the
inputs are simply built without any parameters.

This would have the benefit of not breaking any existing packages regardless
of what parameters are sent to them.
And packages can be modified by maintainers to accept parameters and pass
them on to their inputs as the need arises over time (e.g. packages typically
installed by headless servers can be modified to pass the "-X" flag on to
certain inputs).

Additionally if someone wanted to take the risk and _force_ all inputs to
use the same flags then they can use a function similar to
"package-input-rewriting" (there could be a "package-use-flags-rewriting"),
so it becomes similar to how other types of transformations are currently
handled in Guix.

Ideally packages can still be made to allow all flags to "trickle down" to
their dependencies without input-rewriting simply by passing all parameters
into their inputs in the package definition, but the difference here is that
we don't force it. That's something that can be approached over time, or
not. The idea is to just let packages do it if they want to, and let the
package maintainers filter the list of flags before passing on to inputs if
they need to, and the whole thing becomes more predictable and functional.
This also avoids the problem of which types of inputs to modify (normal
inputs, native-inputs, etc) because then it's just up to the package
maintainer.