Am Donnerstag, dem 11.05.2023 um 20:38 +0530 schrieb Sarthak Shah:
> Hello Guix!
> I'll be working on bringing Parameterized Packages to Guix for GSoC
> 2023 under the guidance of Gábor and Pjotr. I've been a Guix user for
> a few years now as it works great for Common Lisp and Scheme
> projects, and I've always wanted to contribute to it as it has one of
> the best codebases I've seen. Parameterized Packages will serve as an
> awesome feature that leverages Guix's dedication to ensuring that all
> packages can be compiled from source.
> Parameterized Packages will introduce functionality similar to
> Gentoo's USE flags, making it possible to change compile-time options
> for packages. This will provide users with a lot more freedom over
> what features they'd like to include or exclude from packages, and
> also aid with reducing the size of binaries.
> I have provided a detailed outline of parameterized packages and the
> proposed user interface for interacting with them (for both users and
> maintainers) in this post on my blog:
> https://blog.lispy.tech/2023/05/parameterized-packages.html
> I would really appreciate feedback on
> (1) parameters you'd like to see in Guix
Having read your blog and skimmed ahead a little, preferably none with
the way things are currently phrased. That doesn't mean I am against
parameters, but I think it's important to understand them as a package-
local transformations. Failure to do so is imho one of the biggest
flaws in Gentoo's USE flags.
First of all, let's address the elephant in the room: tunable? While
implemented as a package property, that's actually half a parameter.
The tuned package specifies which microarchitecture to optimize the
package for. I think long-term, tunable? should be turned into a
parameter.
Secondly, let's have a look at Emacs.
(package
(name "emacs")
(parameters
(optional jit #t)
(optional png #t)
(optional alsa #t)
(one-of window-system gtk pure-gtk motif none))
...)
looks much nicer than the proposed mix of meaningful names with
symbols. Note, that (one-of ...) takes the first value as implicit
default.
Now you could argue that specifying 20 optional parameters like this
would be a pain in the butt and you prefer your own optional notation.
But have you considered the following syntax as an alternative:
(optionals/enabled jit png alsa)
(optional treesit (some-supported-system-check))
(optionals/disabled xwidgets wide-int ...)
> (2) the user interface for searching/installing/packaging with
> parameters
As with outputs, available parameters ought to be shown in the output
of `guix show', preferably one parameter per line with an explanation
what that parameter does. Note that this isn't supported by either
mockup however, as just like with outputs a place for the documentation
is missing.
For the `guix package' CLI, I'd like to have two options:
--with-parameter=PACKAGE=PARAMETER[=VALUE] enables a parameter
or assigns a specific value to a one-of parameter
--without-parameter=PACKAGE=PARAMETER disables a parameter
If you want to be fancy, you can do
--with-parameters=PACKAGE=PSPEC[,PSPEC...]
where PSPEC is one of
"not PARAMETER" to disable PARAMETER,
"PARAMETER" to enable it,
"PARAMETER=VALUE" to set a specific one-of value
which internally gets lowered to the same specification as equivalent
--with-parameter and --without-parameter arguments.
To support "global" parameters, you could allow PACKAGE to be a regular
expression or if that's too much work, simply allow "*" as a special
package matching all packages. Again, note that I'm not very fond of
global parameters.
For the operating-system side of things, I'd prefer it if we didn't
gain yet another field to care about. I think modify-services should
work well in combination with package transformations, wherein you
simply
(define our-package-parameters
'((with-parameter "emacs=window-system=none")
(without-parameter "emacs=jit")
...))
ahead of time and then use
(options->transformation our-package-parameters)
in the right location.
Cheers
