bug#67292: emacs / emacs-transient collisions and bundling

[Maxime Devos]

Op 22-11-2023 om 21:53 schreef Simon Tournier:
> On mar., 21 nov. 2023 at 19:01, Maxime Devos <maximedevos@telenet.be> wrote:
>
> > Yes, it is official, but the question was how the bundling is not a bug (and
> > implicitly, whether it is bundling), not whether the bundling is official.
>
> The bundling is not a bug because it is how Emacs is developed.

That's what they all say.  What's do different about Emacs that we 
should accept this from Emacs and not from other bundlers?  Like, sure, 
there are some differences in how Emacs bundles things compared to 
others, but how do these differences matter?

> The
> term “bundle“ – which would potentially imply being unbundled by Guix
> packagers – is misleading.

What is misleading about the "term" bundle / misleading about 
potentially being unbundled by Guix packagers?

> Emacs maintainers grant some packages and make them part of Emacs as
> builtin package; whatever where these packages are developed or if these
> packages follow another release schedule than the Emacs release
> schedule.  The section “New Modes and Packages in Emacs X.Y” of the NEWS
> file for each release (NEWS.28, NEWS,27, etc.) lists such promoted
> packages.  Please note that Emacs 29 introduces a “New user option
> 'package-install-upgrade-built-in'”, as mentioned in NEWS.
>
> For instance, the packages widget.el or woman.el or many others were
> initially developed outside the Savannah Emacs tree, then integrated
> (being promoted builtin), and now the original development location is
> gone – which means all the maintenance burden for these builtin packages
> is now done by Emacs maintainers.

Yes, Emacs integrates outside things, I've heard it already ...

If we're talking about misleading statements ...

For widget and woman, sure, I'll take your word for it is fully merged 
in Emacs (both the literal code & development (& maintenance)).  But I'm 
talking about emacs-transient (not widget or woman), and note, as I 
pointed out previously, emacs-transient development location appears to 
be <https://github.com/magit/transient> (which is not the Savannah Emacs 
Tree) -- there's even a new commit 8 hours ago, and it doesn't seem to 
be disappearing anytime soon.

If you have examples, please only use non-misleading examples ...

> Once builtin, the code of a package distributed with GNU Emacs is
> maintained by Emacs maintainers and fully part of GNU Emacs.

Yes, and?  How does being fully part of GNU Emacs and being maintained 
by Emacs maintainers make it any less bundling?  There is more to 
development than maintenance.

Even if we were to exclude situations like this from a definition of 
‘bundling’, that just changes the name of the thing, there still remain 
some benefits to what you aren't calling unbundling / downsides to what 
you aren't calling bundling.

> As explicitly commented in the header of transient.el that comes with
> Emacs:
>
> --8<---------------cut here---------------start------------->8---
> ;;; transient.el --- Transient commands  -*- lexical-binding:t -*-
>
> ;; Copyright (C) 2018-2023 Free Software Foundation, Inc.
>
> ;; Author: Jonas Bernoulli <jonas@bernoul.li>
> ;; URL: https://github.com/magit/transient
>
> [...]
>
> ;; This file is part of GNU Emacs.
> --8<---------------cut here---------------end--------------->8---

Indeed, bundled dependencies are part of what it is bundled inside. 
And?  How does this extra comment matter w.r.t. whether it is bundling 
and whether the bundling is to be tolerated?

> The collision is a bug.  The report of bundled is not a bug.

If that's your opinion, please give you argument on how the bundling of 
emacs-transient, or whatever you want to call it instead of ‘bundling’, 
is not a bug.

--- (From: Mekeor Milere)

> It might be possible to cut out some parts of Emacs so that emacs-minimal is more minimal. But I think this could become quite complicated because we don't know exactly which parts of Emacs are needed to build Emacs-related packages since they might rely on any Elisp code during compile-time. Also, more generally, it'd be hard to decide which parts are not needed, i.e. where to draw the line etc. All in all, I don't think that it's worth the effort and maintenance. 

If making emacs-mnimal more minimal is too complicated, don't do it 
then, just replace the bundled copy with an up-to-date (source) version, 
as I proposed previously.

Also, I don't think I proposed minimalising Emacs to only what's needed 
to build Emacs-related packages (though I could easily be 
misremembering) -- IIRC, I only proposed minimalising it to the extent 
of excluding the bundled Emacs packages.

> TANGENTIALLY: I'd like to mention that this topic becomes sort of a problem when (1) you have installed Emacs with "guix install emacs-next --with-branch=emacs-next=master" or similar; and (2) you installed some Emacs-related package via Guix, which propagates another Emacs-related package that is also built into Emacs. This would cause a downgrade of that propagated, built-in, Emacs-related package. E.g. this happens with emacs-consult-eglot which propagates emacs-eglot which is also built into Emacs itself. A work-around is to overwrite the input like this: "guix install emacs-next emacs-consult-eglot --with-input=emacs-eglot=emacs-next --with-branch=emacs-next=master". 

No?  Unless you do "--with-branch=emacs-next=something-old" or the like, 
you will never get a downgrade -- you will not get an automatic upgrade 
to what's bundled in Emacs-next, but:

 (a) you won't get anything older than what is currently packaged in
     Guix. (Hence, not a downgrade.)
 (b) and you asked for a latest emacs, not a latest emacs-eglot.

You might even get something newer than in the master branch of Emacs, 
if the Emacs maintainers haven't merged in the latest version yet.

Also, I don't get what "--with-input=emacs-eglot=emacs-next" is supposed 
to do.  Like, good for AOT, but this is not a bug report about AOT and 
AFAIK Emacs has automatic recompilation.

> If you want to know which built-in packages are distributed separately via GNU Elpa, 
> search the following file for ":core". Note that only a subset of those might 
> be packaged separately in Guix.
>
>     https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/elpa-packages 

I don't want to know.  I use Guix as package manager, not Emacs -- I 
don't really care whether a hypothetical package is distributed via Elpa.

Best regards,
Maxime Devos.

OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature