Re: Discussion on Parameterized Packages

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

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