[bug#72406] [PATCH emacs-team WIP v3 24/24] gnu: Build all the other emacs-* variants.

[Liliana Marie Prikler]

Am Samstag, dem 10.08.2024 um 20:53 -0500 schrieb Liam Hupfer:
> It seems like getting binary substitutes for more Emacs variants
> shouldn’t require quadrupling the number of top-level Emacs packages
> in Guix. 
You are correct in that we would only require leaf packages, but then
in-between packages wouldn't show up for the user that needs those
instead.

> I assume you used some degree of automation to generate these, but it
> seems like a bit of a pain to maintain, no? 
I'm not sure.  We have a similar setup for Common Lisp, where we build
three variants of everything.  The emacs-xyz.scm file is already too
large though, and should possibly be split up.

> I guess you could implement some sort of CI checking if patches for
> new packages include the correct variants, but it still seems like
> it will lead to an increase in review burden. Seems too easy to make
> typos with the variant prefix, for example. 
I don't think that, tbh.  I've provided a tempel snippet to generate
those variants, maybe someone can add a yasnippet too.

> Plus there are UX issues for end users, like a
> quadrupling in noise from ‘guix search emacs <package>’.
Well, fair, but there's no working around this without producing our
own USE flags, and the project to add those sadly has gone off the
rails IIRC.

> It seems like there must be a way to indicate to Cuirass to build a
> set of packages with rewritten inputs, /without/ exposing those
> packages directly. I believe Nix does something like this by
> providing an ‘emacsPackagesFor’ function that provides an ergonomic
> way for users to target an Emacs variant. See Example
> 6 in [Adding Packages to Emacs — NixOS Manual]. Right now, Guix users
> have to use something like ‘package-input-rewriting’ directly and
> figure out the list of Emacs variants to override to their Emacs
> package, since not all packages use `emacs-minimal'. For binary
> substitutes, the community emacs-overlay project [tells Hydra to
> build] the set of Emacs packages with each common Emacs variant.
I think we can instruct Cuirass to ingest any manifest, but writing and
maintaining that manifest would be pain.  Plus, the other benefit is
that as a user, I can type emacs-*-the-package – for some values of *
at least – and have the correctly built package in my manifest.  No
more fiddling with package-input-rewriting or transformations.

But you are right in that we don't need to introduce more top-level
packages to at least get some of the benefits.  This series does away
with emacs-minimal as the default emacs to build stuff with and
produces a more convenient input rewriting function.  The problem is,
that it is only available to Scheme code, so people using the CLI would
miss out on those packages if not declared publicly.

> We currently don’t have a well-defined “package set” for Emacs
> packages to map rewrites over like Nix, and I don’t know if that is
> ultimately the right solution, but I really don’t think we should
> approach this by adding so many trivial packages to the top-level
> package set. Imagine if we took this approach Guix-wide for
> supporting another libc, for example.
Again, see Common Lisp where we do exactly that.  And yes, it would be
nice to have an easier way of enumerating such package variants, but
I'm not going to hold my breath until we do.

Cheers