Re: Parameterized packages

[Nicolò Balzarotti]

Hello! I've not followed the discussion with too much attention, so
forgive me if I'm plain wrong.
But, if I get this right, to me it seems we want something similar to
what nix is already doing.

Taking handbrake[1] recipe as an example: there's the useGtk flag that
can be passed to the package definition, and that affects build
options. Since in guix dependencies build inputs are specified inside
the package definition, propagating those flags should be easy.  If we
standardize on flags names (don't have "-X", "noX", "disable-x"...), it
should be easy to incrementally add flags support to all package
dependencies.  I imagine (with an invalid syntax probably) something
like:

(inputs
`(,(unless (member build-flags 'no-x) ("libx11" libx11))
  ; this package always need x, don't pass flags
  ("input" ,input "out" (filter (lambda (x) (not (eq? x 'no-x))) build-flags))
  ("other-input" ,input))) ; flags are passed implicitly here?

This would probably increase build recipes complexity a bit (a better
understanding of programs' optional/required features, flasgs available
in guix & co. is required).

If I missed the point, please ignore this message :)

Thanks, Nicolò

[1] 
https://github.com/NixOS/nixpkgs/blob/9ec439e009098b3132848c525a033a602f74faed/pkgs/applications/video/handbrake/default.nix

ison <address@hidden> writes:

> 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.