emacs / emacs-transient collisions and bundling

  • Open
  • quality assurance status badge
Details
3 participants
  • Maxime Devos
  • Mekeor Melire
  • Simon Tournier
Owner
unassigned
Submitted by
Maxime Devos
Severity
normal
M
M
Maxime Devos wrote on 19 Nov 2023 23:44
(name . bug-guix)(address . bug-guix@gnu.org)
5b74251c-e6ab-bb39-7892-3a792ed6854d@telenet.be
Hi,
I recently got the following error message from "guix home build"
(misleading it says "warning" instead):
Toggle quote (4 lines)
> warning: collision encountered:
> /gnu/store/xjrhyapm3zwgpmq5baz6m9kavz287jjj-emacs-29.1/share/info/transient.info.gz
> /gnu/store/lg6h2mkg5z15i78dzvzs0s89bgxxwnlf-emacs-transient-0.4.3-0.cc0fa80/share/info/transient.info.gz
> warning: choosing /gnu/store/xjrhyapm3zwgpmq5baz6m9kavz287jjj-emacs-29.1/share/info/transient.info.gz
Unfortunately, the following doesn't work as minimal reproducer, because
"guix shell" (and likewise for "environment") suppresses collision error
messages:
$ guix shell emacs emacs-transient
(That's not what this bug report is about.)
Bug 1: emacs bundles emacs-transient.
(Likewise for quite a few other Emacs packages.)
Bug 2: no collision handling.
If I'm guessing correctly, emacs-transient is supposed to be a newer
version of the transient bundled in emacs, overriding the bundled
transient in emacs. But for that to work properly, it needs to actually
override the stuff, and going by the collision error message, it isn't
actually overridden but rather the profile building code arbitrarily
chooses between the two.
I guess (guix profiles) should set #:resolve-collision to something
where the "[...]/transient.info.gz" of the store item containing
"[...]/bin/emacs" loses. (And likewise for the other bundled Emacs stuff.)
Best regards,
Maxime Devos
Attachment: OpenPGP_signature
S
S
Simon Tournier wrote on 20 Nov 2023 11:22
86r0kk208a.fsf@gmail.com
Hi,

On Sun, 19 Nov 2023 at 23:44, Maxime Devos <maximedevos@telenet.be> wrote:

Toggle quote (3 lines)
> Bug 1: emacs bundles emacs-transient.
> (Likewise for quite a few other Emacs packages.)

This is not a bug. transient.el is part of Emacs since version 28, see
NEWS:

Toggle snippet (9 lines)
* New Modes and Packages in Emacs 28.1

** transient.el
This library implements support for powerful keyboard-driven menus.
Such menus can be used as simple visual command dispatchers. More
complex menus take advantage of infix arguments, which are somewhat
similar to prefix arguments, but are more flexible and discoverable.

When an user installs Emacs, they expect to have transient as builtin;
it is not bundled. I recommend to read the section:

* New Modes and Packages in Emacs X

in NEWS release files to know which mode or package are included as
builtin. And yes, these packages are sometimes developed outside the
Emacs tree using a dedicated repository, as transient.el or Org-mode for
instance.


Toggle quote (2 lines)
> Bug 2: no collision handling.

This is a bug, IMHO. Indeed, if an user prefers another version of
builtin modes or packages, they should not collide with the builtin
ones. Well, they do not collide when using “guix shell”:

guix shell -C emacs emacs-transient -E TERM -- emacs -q

Therefore, maybe the issue comes from some specific code from “guix
home”. Hum, I do not know.

Cheers,
simon
M
M
Maxime Devos wrote on 20 Nov 2023 13:39
d7740e36-6c7d-35bf-64c1-2218c3e01198@telenet.be
Op 20-11-2023 om 11:22 schreef Simon Tournier:
Toggle quote (22 lines)
> Hi,
>
> On Sun, 19 Nov 2023 at 23:44, Maxime Devos <maximedevos@telenet.be> wrote:
>
>> Bug 1: emacs bundles emacs-transient.
>> (Likewise for quite a few other Emacs packages.)
>
> This is not a bug. transient.el is part of Emacs since version 28, see
> NEWS:
>
> --8<---------------cut here---------------start------------->8---
> * New Modes and Packages in Emacs 28.1
>
> ** transient.el
> This library implements support for powerful keyboard-driven menus.
> Such menus can be used as simple visual command dispatchers. More
> complex menus take advantage of infix arguments, which are somewhat
> similar to prefix arguments, but are more flexible and discoverable.
> --8<---------------cut here---------------end--------------->8---
>
> When an user installs Emacs, they expect to have transient as builtin;
> it is not bundled.
This does not answer how the bundling is not a bug.
Unbundling is not incompatible with keeping builtins -- for example,
emacs-minimal could be the ‘minimalistic Emacs, without the typical
bundled ‘built-in’ stuff’, and emacs could be 'emacs-minimal + the
unbundled stuff in propagated-inputs’.
(Well, preferably not propagated, but that's just a matter of wrapping
or unions etc..)
Another option could be to unbundle things in the 'source' of emacs /
emacs-minimal and copy over source code from the 'emacs-‘builtin’'
packages during a build phase.
(IIUC, emacs-minimal is for compiling Emacs packages and for scripts, of
which most probably have no need for keyboard-driven menus -- and if
they do have need,)
Toggle quote (6 lines)
> I recommend to read the section:
>
> * New Modes and Packages in Emacs X
>
> in NEWS release files to know which mode or package are included as
> builtin.
I won't -- my package manager is Guix, not Emacs.
Toggle quote (15 lines)
> And yes, these packages are sometimes developed outside the
> Emacs tree using a dedicated repository, as transient.el or Org-mode for
> instance.
>
>
>> Bug 2: no collision handling.
>
> This is a bug, IMHO. Indeed, if an user prefers another version of
> builtin modes or packages, they should not collide with the builtin
> ones. Well, they do not collide when using “guix shell”:
>
> guix shell -C emacs emacs-transient -E TERM -- emacs -q
>
> Therefore, maybe the issue comes from some specific code from “guix
> home”. Hum, I do not know.
They do, in fact, collide -- as I mentioned in the e-mail you replied to:
Toggle quote (7 lines)
> [...] because
> "guix shell" (and likewise for "environment") suppresses collision error
> messages:
>
> $ guix shell emacs emacs-transient
>
> (see: https://issues.guix.gnu.org/54350).
Best regards,
Maxime Devos
Attachment: OpenPGP_signature
M
M
Maxime Devos wrote on 20 Nov 2023 13:42
e382f178-e6b9-a4da-7f6e-919778deaf37@telenet.be
Toggle quote (19 lines)
>>> Bug 2: no collision handling.
>>
>> This is a bug, IMHO.  Indeed, if an user prefers another version of
>> builtin modes or packages, they should not collide with the builtin
>> ones.  Well, they do not collide when using “guix shell”:
>>
>>      guix shell -C emacs emacs-transient -E TERM -- emacs -q
>>
>> Therefore, maybe the issue comes from some specific code from “guix
>> home”.  Hum, I do not know.
>
> They do, in fact, collide -- as I mentioned in the e-mail you replied to:
>
>> [...] because "guix shell" (and likewise for "environment") suppresses
>> collision error messages:
>>
>> $ guix shell emacs emacs-transient
>>
>> (see: https://issues.guix.gnu.org/54350).
More info: (guix profiles) does not seem to handle this anywhere.
Attachment: OpenPGP_signature
S
S
Simon Tournier wrote on 20 Nov 2023 14:46
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 67292@debbugs.gnu.org)
CAJ3okZ3J_n0cbH4_v2s-tXS+BaX56nOf+okB5OZ4Ak-rCHcG2Q@mail.gmail.com
On Mon, 20 Nov 2023 at 13:39, Maxime Devos <maximedevos@telenet.be> wrote:

Toggle quote (2 lines)
> This does not answer how the bundling is not a bug.

It answers. Nothing is bundled. It is the official Emacs.


Toggle quote (4 lines)
> (IIUC, emacs-minimal is for compiling Emacs packages and for scripts, of
> which most probably have no need for keyboard-driven menus -- and if
> they do have need,)

Here, you are speaking about another thing. Please open another bug
report for that: is emacs-minimal really minimal? Or could some
builtin modes and packages be dropped because they are not required
for building Emacs packages?


All the best,
simon
M
M
Maxime Devos wrote on 21 Nov 2023 19:01
(name . Simon Tournier)(address . zimon.toutoune@gmail.com)(address . 67292@debbugs.gnu.org)
fa20a80b-608b-ec9b-2995-b0c4e865a9b0@telenet.be
Op 20-11-2023 om 14:46 schreef Simon Tournier:
Toggle quote (5 lines)
> On Mon, 20 Nov 2023 at 13:39, Maxime Devos <maximedevos@telenet.be> wrote:
>
>> This does not answer how the bundling is not a bug.
>
> It answers. Nothing is bundled. It is the official Emacs.
‘Nothing is bundled’: on the contrary:
* ‘New Modes and Packages in Emacs 28.1'
* + a separate emacs-transient exists, and emacs-transient appears to
be developed outside Emacs:
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.
Toggle quote (8 lines)
>> (IIUC, emacs-minimal is for compiling Emacs packages and for scripts, of
>> which most probably have no need for keyboard-driven menus -- and if
>> they do have need,)
>
> Here, you are speaking about another thing. Please open another bug
> report for that: is emacs-minimal really minimal? Or could some
> builtin modes and packages be dropped because they are not required
> for building Emacs packages?
Not interested.
Best regards,
Maxime Devos.
Attachment: OpenPGP_signature
M
M
Mekeor Melire wrote on 23 Nov 2023 15:17
(name . Maxime Devos)(address . maximedevos@telenet.be)
87jzq8bke0.fsf@posteo.de
Hello Maxime,

2023-11-20 13:39 maximedevos@telenet.be:

Toggle quote (38 lines)
> Op 20-11-2023 om 11:22 schreef Simon Tournier:

> > On Sun, 19 Nov 2023 at 23:44, Maxime Devos
> > <maximedevos@telenet.be>
> > wrote:

> >> Bug 1: emacs bundles emacs-transient.
> >> (Likewise for quite a few other Emacs packages.)

> > This is not a bug. transient.el is part of Emacs since
> > version 28,

> This does not answer how the bundling is not a bug.
>
> Unbundling is not incompatible with keeping builtins -- for
> example,
> emacs-minimal could be the ‘minimalistic Emacs, without the
> typical
> bundled ‘built-in’ stuff’, and emacs could be 'emacs-minimal +
> the
> unbundled stuff in propagated-inputs’.
>
> (Well, preferably not propagated, but that's just a matter of
> wrapping
> or unions etc..)
>
> Another option could be to unbundle things in the 'source' of
> emacs /
> emacs-minimal and copy over source code from the
> 'emacs-‘builtin’'
> packages during a build phase.
>
> (IIUC, emacs-minimal is for compiling Emacs packages and for
> scripts,
> of which most probably have no need for keyboard-driven menus --
> and
> if they do have need,)

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.

Toggle quote (2 lines)
> >> Bug 2: no collision handling.

As far as I know, Guix does not provide a facility to prioritize a
file from one package over the same file from another package.

But also, I don't think this is necessary here, because in a Guix-installed Emacs, the paths to Guix-installed Emacs-related packages appear first in Emacs' load-path variable, whereas the paths to the elisp-directories from Emacs itself come last. Thus, emacs-transient's transient.el is always preferred over Emacs' transient.el.

Finally, here's a list an incomplete list of Emacs-related packages that are both built into Emacs itself, as well as distributed separately over GNU Elpa and thus also as separate packages in Guix:

emacs-eglot
emacs-eldoc
emacs-external-completion
emacs-jsonrpc
emacs-let-alist
emacs-map
emacs-ntlm
emacs-project
emacs-so-long
emacs-soap-client
emacs-use-package
emacs-xref

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.


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".
S
S
Simon Tournier wrote on 22 Nov 2023 21:53
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 67292@debbugs.gnu.org)
87fs0xpl1t.fsf@gmail.com
On mar., 21 nov. 2023 at 19:01, Maxime Devos <maximedevos@telenet.be> wrote:

Toggle quote (3 lines)
> 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. The
term “bundle“ – which would potentially imply being unbundled by Guix
packagers – is misleading.

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.

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

As explicitly commented in the header of transient.el that comes with
Emacs:

Toggle snippet (12 lines)
;;; 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.

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

Cheers,
simon
M
M
Maxime Devos wrote on 28 Nov 2023 01:58
55357bdc-cdfe-c264-7618-f69681565fb6@telenet.be
Op 23-11-2023 om 15:17 schreef Mekeor Melire:
Toggle quote (4 lines)
>> >> Bug 2: no collision handling.
>
> As far as I know, Guix does not provide a facility to prioritize a
> file from one package over the same file from another package.
As I mentioned in a previous e-mail in #67292, it does provide a
facility -- not mentioned: by default, the first package in the list is
prioritized.
Toggle quote (1 lines)
> But also, I don't think this is necessary here, because in a Guix-installed Emacs, the paths to Guix-installed Emacs-related packages appear first in Emacs' load-path variable, whereas the paths to the elisp-directories from Emacs itself come last. Thus, emacs-transient's transient.el is always preferred over Emacs' transient.el.
If the collision is not a problem then Guix shouldn't be warning about
it -- as such, the collision handling needs to be adjusted to not emit a
warning in this case.
Best regards,
Maxime Devos
Attachment: OpenPGP_signature
M
M
Maxime Devos wrote on 28 Nov 2023 02:47
(address . 67292@debbugs.gnu.org)
daacad7f-20f7-3781-1137-0f85731c88ea@telenet.be
Op 22-11-2023 om 21:53 schreef Simon Tournier:
Toggle quote (6 lines)
> 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?
Toggle quote (3 lines)
> 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?
Toggle quote (13 lines)
> 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 ...
Toggle quote (2 lines)
> 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.
Toggle quote (15 lines)
> 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?
Toggle quote (1 lines)
> 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)
Toggle quote (1 lines)
> 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.
Toggle quote (1 lines)
> 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.
Toggle quote (3 lines)
> 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.
Attachment: OpenPGP_signature
M
M
Mekeor Melire wrote on 28 Nov 2023 12:12
(name . Maxime Devos)(address . maximedevos@telenet.be)
87edgajfim.fsf@posteo.de
2023-11-28 01:58 maximedevos@telenet.be:

Toggle quote (12 lines)
> [[PGP Signed Part:Undecided]]
> Op 23-11-2023 om 15:17 schreef Mekeor Melire:
> >> >> Bug 2: no collision handling.
> > As far as I know, Guix does not provide a facility to
> > prioritize a
> > file from one package over the same file from another package.
>
> As I mentioned in a previous e-mail in #67292, it does provide a
> facility -- not mentioned: by default, the first package in the
> list
> is prioritized.

Sorry for the oversight. Which list are you referring to?

Toggle quote (6 lines)
> If the collision is not a problem then Guix shouldn't be warning
> about
> it -- as such, the collision handling needs to be adjusted to
> not emit
> a warning in this case.

True. That'd be nice. Should we discuss this here, in this bug-report or in another, new bug-report that is dedicated to the problem of unnecessary collision-warnings?
M
M
Mekeor Melire wrote on 28 Nov 2023 12:15
(name . Maxime Devos)(address . maximedevos@telenet.be)
87a5qyjecf.fsf@posteo.de
2023-11-28 02:47 maximedevos@telenet.be:
Toggle quote (18 lines)
> Op 22-11-2023 om 21:53 schreef Simon Tournier:
> > On mar., 21 nov. 2023 at 19:01, Maxime Devos
> > <maximedevos@telenet.be> wrote:

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

Note that transient.el from Emacs-master and from github.com/magit/transient actually have diverged. In particular, the following commit is present on Emacs-master while it is not present on magit/transient: https://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/transient.el?id=7705bdfa5b89f78dab049f73f636b9680a3c12bc

The relation between the possibly-existing separate repository of an Emacs-core-package (e.g. github.com/magit/transient) to the Emacs-repository itself seems to depend on the concrete package. As we just saw, for transient.el, that its version in the separate repository and in the Emacs-repository may temporarily diverge. Tarsius, the transient-maintainer, merges changes into Emacs after version bumps.

Another example is eglot.el. It also has a separate repository but that repository is only occasionally synced with the more progressed version that is tracked in the Emacs repository itself.

Toggle quote (2 lines)
> --- (From: Mekeor Milere)

It's "Melire". Why did you respond to my mail in a separate thread?

Toggle quote (5 lines)
> 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.

Replacing the "bundled copy" could erase fixes, that are only present in Emacs, and not present in github.com/magit/transient.

Toggle quote (35 lines)
> > 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.

As elaborated before, some packages (like Eglot) are primarily developed in the Emacs repository. (Unlike Transient.)

Toggle quote (3 lines)
> Also, I don't get what "--with-input=emacs-eglot=emacs-next" is
> supposed to do.

It effectively removes emacs-eglot as input for the installed packages and their dependencies

Toggle quote (13 lines)
> > 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.

The point is that Guix downloads the source code of (some?) Elpa-distributed packages from Elpa. For example: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/emacs-xyz.scm?h=60c97924e9519361494aaf0686e28eb831a42315#n1011
S
S
Simon Tournier wrote on 28 Nov 2023 10:45
(address . 67292@debbugs.gnu.org)
868r6igqi2.fsf@gmail.com
On Tue, 28 Nov 2023 at 02:47, Maxime Devos <maximedevos@telenet.be> wrote:

Toggle quote (7 lines)
>> 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.

Please read GNU Emacs documentation and how GNU Emacs is developed. I
have tried to do my best for pointing you some links. If these are not
enough, you should dig by your own. Maybe ask on emacs-devel mailing
list how the GNU Emacs development process works.

Toggle quote (4 lines)
> 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.

This is *not* the GNU Emacs release model. GNU Emacs version X.Y *is*
all the exact same files as the ones stored in Savannah. If you want to
replace the file
/gnu/store/…-emacs-X.Y/share/emacs/X.Y/lisp/transient.el.gz by something
else, you need to package that exact file. Therefore, your proposal
would imply to have two packages:

+ emacs-transient-next following development of transient.el – this
development happens outside Savannah. Please note for other builtin
packages, this development happens inside the Emacs repository
located in Savannah.

+ emacs-transient providing the exact same version as the builtin one
tracked in the GNU Emacs release X.Y branch located in Savannah.

Again, transient.el is not bundled. It is a builtin package which means
it is fully part of GNU Emacs. Being developed outside Savannah does
not make it bundled.


Regards,
simon
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 67292@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 67292
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch