GNU bug report logs - #63920
Allow for easily rewriting Emacs packages to use emacs-next

Previous Next

To reply to this bug, email your comments to 63920 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mekeor Melire <mekeor <at> posteo.de>
To: bug-guix <at> gnu.org
Subject: Emacs Packages should have an output built with emacs-next(-minimal)
Date: Tue, 06 Jun 2023 07:11:28 +0000

Hello dear Guix community,

if I understand correctly, all Emacs-packages that are packaged in 
Guix proper, are built with Emacs version 28 (or more precisely, 
emacs-minimal <at> 28, emacs <at> 28, emacs-no-x <at> 28, emacs-no-x-toolkit <at> 28 
or emacs-wide-int <at> 28 (except emacs-jsdoc which is and needs to be 
built with emacs-next <at> 29)). (You may grep the Guix repository for 
":emacs" to find out by yourself.)

When using these Emacs-packages with emacs-next* (i.e. version 29 
or 30), this can lead to misbehavior because Emacs will still 
prefer the compiled .elc or .eln files which may depend on version 
28 specifics.

My concrete experience is that, when using emacs-next-tree-sitter 
and emacs-consult packages, evaluating (require 'consult-register) 
fails because it has emacs-major-version-specific code: 
https://github.com/minad/consult/blob/3c0f87ebd20b25f03568fb9ef8fd36b5a2a6eb84/consult-register.el#L82 
(A workaround is to instead evaluate (load 
"consult-register.el").)

I propose:

1. Introduce a package emacs-next-minimal.

2. For all Emacs-packages, create one output corresponding to each 
Emacs major-version packaged in Guix proper. For example, the 
output "emacs-next" would be built with emacs-next-minimal.

What do you think? I'd guess this should be hard to implement, 
right?

Kindly
Mekeor

Message #8 received at 63920 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Mekeor Melire <mekeor <at> posteo.de>, 63920 <at> debbugs.gnu.org
Subject: Re: Emacs Packages should have an output built with
 emacs-next(-minimal)
Date: Tue, 06 Jun 2023 18:07:42 +0200

Hi Mekeor,

Am Dienstag, dem 06.06.2023 um 07:11 +0000 schrieb Mekeor Melire:
> Hello dear Guix community,
> 
> if I understand correctly, all Emacs-packages that are packaged in 
> Guix proper, are built with Emacs version 28 (or more precisely, 
> emacs-minimal <at> 28, emacs <at> 28, emacs-no-x <at> 28, emacs-no-x-toolkit <at> 28 
> or emacs-wide-int <at> 28 (except emacs-jsdoc which is and needs to be 
> built with emacs-next <at> 29)). (You may grep the Guix repository for 
> ":emacs" to find out by yourself.)
Emacs packages other than emacs-minimal should be the exception rather
than the norm.  

> When using these Emacs-packages with emacs-next* (i.e. version 29 
> or 30), this can lead to misbehavior because Emacs will still 
> prefer the compiled .elc or .eln files which may depend on version 
> 28 specifics.
It should not prefer the .eln files, which get put into a unique
directory per Emacs – yes, that ought to include different versions of
the emacs package itself built with inputs that had their hashes
changed.  In any case, the version number itself (28 vs 29) is enough
to turn .eln loading away.

For .elc, the behaviour is indeed as you described, but that's rather
due to the fact that bytecode ought to be forward-compatible.  The
packages you describe below thus invoke (IIUC) undefined behaviour.

> My concrete experience is that, when using emacs-next-tree-sitter 
> and emacs-consult packages, evaluating (require 'consult-register) 
> fails because it has emacs-major-version-specific code: 
> https://github.com/minad/consult/blob/3c0f87ebd20b25f03568fb9ef8fd36b5a2a6eb84/consult-register.el#L82
>  
> (A workaround is to instead evaluate (load 
> "consult-register.el").)
> 
> I propose:
> 
> 1. Introduce a package emacs-next-minimal.
> 
> 2. For all Emacs-packages, create one output corresponding to each 
> Emacs major-version packaged in Guix proper. For example, the 
> output "emacs-next" would be built with emacs-next-minimal.
> 
> What do you think? I'd guess this should be hard to implement, 
> right?
This would unnecessarily complicate things over at emacs-build-system.
Now, emacs-next-minimal itself might be worthwhile (I don't see a
strong reason as to why, though), but since native compilation was
introduced to Guix, the recommendation was to compile packages ahead of
time rather than using the built-in JIT.  To do so, add 
  --with-input=emacs-minimal=emacs-next
or use a semantically equivalent options->transformation.  

As for a long-term solution to the problem, I do think we could make
the situation easier by providing dedicated alternatives (e.g. "emacs-
next-consult") or using parameterized packages (which is a larger TODO
than emacs-build-system, however).  As a member of the emacs-team, I do
have to sadly report that we have yet to start the most serious work
for making emacs-next the new emacs.

Cheers

Message #11 received at 63920 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: Mekeor Melire <mekeor <at> posteo.de>, GNU Debbugs <control <at> debbugs.gnu.org>,
 63920 <at> debbugs.gnu.org
Subject: Re: bug#63920: Emacs Packages should have an output built with
 emacs-next(-minimal)
Date: Tue, 03 Oct 2023 22:20:59 -0400

retitle 63920 Allow for easily rewriting Emacs packages to use emacs-next
quit

Hello Mekeor,

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

[...]

>> (A workaround is to instead evaluate (load 
>> "consult-register.el").)
>> 
>> I propose:
>> 
>> 1. Introduce a package emacs-next-minimal.
>> 
>> 2. For all Emacs-packages, create one output corresponding to each 
>> Emacs major-version packaged in Guix proper. For example, the 
>> output "emacs-next" would be built with emacs-next-minimal.
>> 
>> What do you think? I'd guess this should be hard to implement, 
>> right?
> This would unnecessarily complicate things over at emacs-build-system.
> Now, emacs-next-minimal itself might be worthwhile (I don't see a
> strong reason as to why, though), but since native compilation was
> introduced to Guix, the recommendation was to compile packages ahead of
> time rather than using the built-in JIT.  To do so, add 
>   --with-input=emacs-minimal=emacs-next
> or use a semantically equivalent options->transformation.  

I agree adding multiple outputs would make things complicated and messy,
and should thus not be the approach pursued.  I think this should be
feasible via package rewriting procedures, like we had in the past for
Python 2 with package-for-python2 or similar, which users can apply to
their Emacs package collection in a manifest file.

A version of it for Emacs has been shared to guix-devel in the past, it
could be reworked, it had some problems still.

I'm renaming the issue to something that should serve as a reminder to
someone to implement this.

-- 
Thanks,
Maxim

Message #16 received at 63920 <at> debbugs.gnu.org (full text, mbox):

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Mekeor Melire <mekeor <at> posteo.de>, GNU Debbugs <control <at> debbugs.gnu.org>,
 63920 <at> debbugs.gnu.org, Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Subject: Re: bug#63920: Allow for easily rewriting Emacs packages to use
 emacs-next
Date: Wed, 04 Oct 2023 11:14:07 +0200

Hi,

On Tue, 03 Oct 2023 at 22:20, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:

> I agree adding multiple outputs would make things complicated and messy,
> and should thus not be the approach pursued.  I think this should be
> feasible via package rewriting procedures, like we had in the past for
> Python 2 with package-for-python2 or similar, which users can apply to
> their Emacs package collection in a manifest file.

For the record, it remembers these related or similar discussions:

    https://issues.guix.gnu.org/issue/41732
    https://issues.guix.gnu.org/issue/64586

Cheers,
simon

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.