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

[Liam Hupfer via Guix-patches via <guix-patches@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 4965 bytes --]

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Samstag, dem 10.08.2024 um 20:53 -0500 schrieb Liam Hupfer:
>> 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.

That’s unfortunate 😅.

> The emacs-xyz.scm file is already too large though, and should
> possibly be split up.

I definitely agree with that.

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

Editor-specific conveniences are nice, but it doesn’t change how manual
the approach is. I doubt one-time contributors tend to set up the
snippets. We have the full power of Scheme at our disposal, so it seems
like we can do better than N×M Emacs packages, where N is the number of
Emacs variants and M is the number of Emacs Lisp package sources.

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

Maintaining such a manifest, with a single list of Emacs variants and a
single list of Emacs packages to map over, seems far more manageable to
me than to define top-level packages for multiple Emacs variants, where
the variants provided for each package are hardcoded and only kept
consistent by judicious patch review.

Plus, with your more convenient rewriting functions, I think we can
better document this in the manual. Currently the note in `(guix)
Application Setup' only mentions `--with-input', but we should include a
snippet of how to do this declaratively as well.

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

Can’t people using the CLI use `--with-input'? Not very ergonomic, but
regardless, people using the CLI are still limited to whatever
semi-arbitrary set of variants we enumerate, e.g. `emacs-pgtk-xwidgets'
and any non-default `emacs-next' variant are not currently supported.

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

I feel like Common Lisp already doing it is not sufficient justification
to proliferate the approach. I don’t think it scales well for any
package ecosystem. Between finding a way to tell Cuirass to build
substitutes for more Emacs variants and improving documentation on
installing natively compiled packages for a particular variant, I think
we can sufficiently improve the status quo without the package
explosion. But I’m not experienced enough yet to implement what I’m
describing, so I can’t really back up my claims with code, only links to
the Nix approach.

Thanks for responding to my feedback. Good luck with whatever you
decide!

—Liam