GNU bug report logs -
#72406
[PATCH emacs-team WIP 0/4] Simplify creation of emacs package variants
Previous Next
Full log
Message #137 received at 72406 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Liliana Marie Prikler <liliana.prikler <at> 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
This bug report was last modified 284 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.