Implement a wrapper so users can build the Emacs packages using a version of their choosing

  • Open
  • quality assurance status badge
Details
5 participants
  • Fredrik Salomonsson via web
  • Nicolas Goaziou
  • Maxim Cournoyer
  • Fredrik Salomonsson
  • zimoun
Owner
unassigned
Submitted by
Fredrik Salomonsson
Severity
normal
F
F
Fredrik Salomonsson wrote on 6 Jun 2020 05:14
issue with emacs-lua-mode and emacs-next
(address . bug-guix@gnu.org)
CABZcOATXwbLV71GCvP1ZksKjJyrU9OH4k1CEfHXLPysbFTmCEQ@mail.gmail.com
Hi,

When I launch emacs (emacs-next) with the emacs-lua-mode package, I'm
getting this error
"Error (use-package): lua-mode/:catch: Unknown rx form ‘symbol’"

It works when I let emacs download it from melpa. I tried updating
emacs-lua-mode to 20200508, which is the same version as on melpa.

Still the same issue.

Could this be an issue that it's using emacs-minimal-26.3 to byte compile
the files? Where I'm using emacs-next aka emasc-27.0. Judging by this issue
[1] the rx package has gone through some changes in 27.0.

I've attached the backtrace and the patch for the latest emacs-lua-mode.

Thanks

--
s/Fred[re]+i[ck]+/Fredrik/g
Attachment: file
Attachment: emacs-lua-mode.backtrace
From 1ef949ea0a9bdec2bdf42c0314b8e8e01acff72d Mon Sep 17 00:00:00 2001
From: Fredrik Salomonsson <plattfot@gmail.com>
Date: Fri, 5 Jun 2020 19:39:37 -0700
Subject: [PATCH] gnu: emacs-lua-mode: Update to 20200508-0.35b6e4c.

* gnu/packages/emacs-xyz.scm (emacs-lua-mode): Update to 20200508-0.35b6e4c.
---
gnu/packages/emacs-xyz.scm | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

Toggle diff (39 lines)
diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index 6110374281..e2d91918e8 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -8292,11 +8292,11 @@ using package inferred style.")
(license license:gpl3+))))
(define-public emacs-lua-mode
- (let ((commit "1f596a93b3f1caadd7bba01030f8c179b029600b")
- (revision "1"))
+ (let ((commit "35b6e4c20b8b4eaf783ccc8e613d0dd06dbd165c")
+ (revision "0"))
(package
(name "emacs-lua-mode")
- (version (git-version "20191204" revision commit))
+ (version (git-version "20200508" revision commit))
(home-page "https://github.com/immerrr/lua-mode/")
(source (origin
(method git-fetch)
@@ -8306,14 +8306,14 @@ using package inferred style.")
(file-name (git-file-name name version))
(sha256
(base32
- "0i4adlaik3qjx1wkb7rwk2clvj7ci2g8pm0siyb3yk90r6z5mspi"))))
+ "1hai6rqjm5py0bp57nhggmj9qigwdj3a46ngacpnjc1qmy9kkgfk"))))
(build-system emacs-build-system)
(arguments
`(#:tests? #t
- #:test-command '("buttercup" "-l" "lua-mode.el")))
+ #:test-command '("buttercup" "-l" "lua-mode.el")))
(native-inputs
`(("emacs-buttercup" ,emacs-buttercup)
- ("lua" ,lua)))
+ ("lua" ,lua)))
(synopsis "Major mode for lua")
(description
"This Emacs package provides a mode for @uref{https://www.lua.org/,
--
2.26.2
F
F
Fredrik Salomonsson via web wrote on 6 Jun 2020 05:17
(address . 41732@debbugs.gnu.org)
7fb638338760.d015b5866f7291e@guile.gnu.org
Forgot to say which guix version I'm using:

guix (GNU Guix) ba6d3612550f5d978c4b5b1df122444f8fb29377
N
N
Nicolas Goaziou wrote on 6 Jun 2020 10:10
(name . Fredrik Salomonsson)(address . plattfot@gmail.com)(address . 41732@debbugs.gnu.org)
87tuzo8vj6.fsf@nicolasgoaziou.fr
Hello,

Fredrik Salomonsson <plattfot@gmail.com> writes:

Toggle quote (13 lines)
> When I launch emacs (emacs-next) with the emacs-lua-mode package, I'm
> getting this error
> "Error (use-package): lua-mode/:catch: Unknown rx form ‘symbol’"
>
> It works when I let emacs download it from melpa. I tried updating
> emacs-lua-mode to 20200508, which is the same version as on melpa.
>
> Still the same issue.
>
> Could this be an issue that it's using emacs-minimal-26.3 to byte compile
> the files? Where I'm using emacs-next aka emasc-27.0. Judging by this issue
> [1] the rx package has gone through some changes in 27.0.

This seems to be reported upstream as


You may be right. Files byte-compiled with Emacs 26 may not be
compatible with Emacs 27.

I don't know what can be done on Guix's side, tho.

Toggle quote (3 lines)
> I've attached the backtrace and the patch for the latest
> emacs-lua-mode.

Could you send another bug report for the package update?

Regards,

--
Nicolas Goaziou
Z
Z
zimoun wrote on 6 Jun 2020 12:26
(name . Nicolas Goaziou)(address . mail@nicolasgoaziou.fr)
CAJ3okZ08+N=2t+LwgbMphWGFBrMUPBFgWdRBQ=Mmk5Cpos_UvA@mail.gmail.com
Dear Nicolas,

On Sat, 6 Jun 2020 at 10:11, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

Toggle quote (5 lines)
> You may be right. Files byte-compiled with Emacs 26 may not be
> compatible with Emacs 27.
>
> I don't know what can be done on Guix's side, tho.

Somehow, one needs to change the Emacs version used by the Emacs
toolchain to bytecompile, right?
I do not know if it makes sense, but we could add something like
'package-with-emacs-next' similar to 'package-with-python2' or
'package-with-ocam4.07'.
WDYT?


All the best,
simon
N
N
Nicolas Goaziou wrote on 6 Jun 2020 16:13
(name . zimoun)(address . zimon.toutoune@gmail.com)
87sgf8ffj9.fsf@nicolasgoaziou.fr
Hello,

zimoun <zimon.toutoune@gmail.com> writes:

Toggle quote (7 lines)
> Somehow, one needs to change the Emacs version used by the Emacs
> toolchain to bytecompile, right?
> I do not know if it makes sense, but we could add something like
> 'package-with-emacs-next' similar to 'package-with-python2' or
> 'package-with-ocam4.07'.
> WDYT?

This sounds like serious overhead for a single package. Maybe we could
try to prevent byte-compilation for the package and see what happens?

Regards,

--
Nicolas Goaziou
Z
Z
zimoun wrote on 6 Jun 2020 17:30
(name . Nicolas Goaziou)(address . mail@nicolasgoaziou.fr)
CAJ3okZ3JoFb3T_f=bnLxNxGnD1FDcxzoODP29+5bi9MT-K7Jrw@mail.gmail.com
Dear Nicolas,

On Sat, 6 Jun 2020 at 16:13, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
Toggle quote (12 lines)
> zimoun <zimon.toutoune@gmail.com> writes:

> > Somehow, one needs to change the Emacs version used by the Emacs
> > toolchain to bytecompile, right?
> > I do not know if it makes sense, but we could add something like
> > 'package-with-emacs-next' similar to 'package-with-python2' or
> > 'package-with-ocam4.07'.
> > WDYT?
>
> This sounds like serious overhead for a single package. Maybe we could
> try to prevent byte-compilation for the package and see what happens?

Maybe I miss the issue. From my understanding, all the Emacs packages
are byte-compiled with the current Emacs. Therefore, "guix install
emacs-next emacs-foo" and then "M-x foo" works by luck -- well because
the Emacs VM is stable. :-)
And I do not know how to rebuild all my Emacs packages using
'emacs-next' instead of the current Emacs. Maybe I miss something.

Well, I am not suggesting to duplicate all the Emacs packages with
something like 'emacs-next-<package>' because it is too much. I am
suggesting to provide 'package-with-emacs-next' and then for example
in my manifest file I would use this new procedure to generate
on-the-fly these next packages; as an expert Emacs mode.

I do not know if this proposal makes sense. Probably not. :-)
(My regular Emacs is the current version and I very rarely use
emacs-next because I started Emacs with 23 therefore 24 was already a
so-nice improvement. :-))

All the best,
simon
M
M
Maxim Cournoyer wrote on 7 Jun 2020 06:39
(name . zimoun)(address . zimon.toutoune@gmail.com)
877dwj4hho.fsf@gmail.com
Hello,

zimoun <zimon.toutoune@gmail.com> writes:

Toggle quote (20 lines)
> Dear Nicolas,
>
> On Sat, 6 Jun 2020 at 16:13, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>> zimoun <zimon.toutoune@gmail.com> writes:
>
>> > Somehow, one needs to change the Emacs version used by the Emacs
>> > toolchain to bytecompile, right?
>> > I do not know if it makes sense, but we could add something like
>> > 'package-with-emacs-next' similar to 'package-with-python2' or
>> > 'package-with-ocam4.07'.
>> > WDYT?
>>
>> This sounds like serious overhead for a single package. Maybe we could
>> try to prevent byte-compilation for the package and see what happens?
>
> Maybe I miss the issue. From my understanding, all the Emacs packages
> are byte-compiled with the current Emacs. Therefore, "guix install
> emacs-next emacs-foo" and then "M-x foo" works by luck -- well because
> the Emacs VM is stable. :-)

That's a good description of the situation. There's no warranty that
emacs-something works with emacs-next unless it was packaged to be
compiled specifically with emacs-next instead of the default emacs package
(currently 26.3).

Toggle quote (3 lines)
> And I do not know how to rebuild all my Emacs packages using
> 'emacs-next' instead of the current Emacs. Maybe I miss something.

Some people have been adding emacs-next-something packages (IIRC); I
think it's OK for the big, complicated packages that need effort to
port, but otherwise I wouldn't like seeing this happening for all
packages.

Toggle quote (6 lines)
> Well, I am not suggesting to duplicate all the Emacs packages with
> something like 'emacs-next-<package>' because it is too much. I am
> suggesting to provide 'package-with-emacs-next' and then for example
> in my manifest file I would use this new procedure to generate
> on-the-fly these next packages; as an expert Emacs mode.

That sounds like a good idea; provide a way for users to rewrite their
package at the level of their manifest file (which is already possible
IIUC).

Toggle quote (5 lines)
> I do not know if this proposal makes sense. Probably not. :-)
> (My regular Emacs is the current version and I very rarely use
> emacs-next because I started Emacs with 23 therefore 24 was already a
> so-nice improvement. :-))

It does make sense. For those who would like to see our base Emacs
package be updated to emacs-next, we need to iron out all the packages
currently failing to build with it. It is easy to try, by modifying
slightly a local Guix checkout:

Toggle snippet (16 lines)
1 file changed, 1 insertion(+), 1 deletion(-)
guix/build-system/emacs.scm | 2 +-

modified guix/build-system/emacs.scm
@@ -52,7 +52,7 @@
"Return the default Emacs package."
;; Lazily resolve the binding to avoid a circular dependency.
(let ((emacs-mod (resolve-interface '(gnu packages emacs))))
- (module-ref emacs-mod 'emacs-minimal)))
+ (module-ref emacs-mod 'emacs-next)))
(define* (lower name
#:key source inputs native-inputs outputs system target


Maxim
Z
Z
zimoun wrote on 7 Jun 2020 11:31
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
CAJ3okZ1-=iodmfNCmxxW_W621s-H8zFc5PRViHcs6nOY14qPMg@mail.gmail.com
Dear Maxim,

On Sun, 7 Jun 2020 at 06:39, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

Toggle quote (5 lines)
> Some people have been adding emacs-next-something packages (IIRC); I
> think it's OK for the big, complicated packages that need effort to
> port, but otherwise I wouldn't like seeing this happening for all
> packages.

I agree. I am not suggesting to duplicate all the packages with
'emacs-next-something'. There is already enough to do with the
current ones. :-)


Toggle quote (10 lines)
> > Well, I am not suggesting to duplicate all the Emacs packages with
> > something like 'emacs-next-<package>' because it is too much. I am
> > suggesting to provide 'package-with-emacs-next' and then for example
> > in my manifest file I would use this new procedure to generate
> > on-the-fly these next packages; as an expert Emacs mode.
>
> That sounds like a good idea; provide a way for users to rewrite their
> package at the level of their manifest file (which is already possible
> IIUC).

I propose to provide 'package-with-emacs-next' for the people in the
experimental mood. :-) For example, the manifest looks like:

Toggle snippet (13 lines)
(use-modules (guix build-system emacs)
(gnu packages emacs)
(gnu packages emacs-xyz))

(packages->manifest
(cons emacs-next
(map
package-with-emacs-next
(list
emacs-lua-mode
emacs-magit))))

Then the expert uses it with:

guix package -m manifest.scm

Well, the attached patch does that. And maybe, an entry to the
Cookbook could be worth.


Toggle quote (27 lines)
> > I do not know if this proposal makes sense. Probably not. :-)
> > (My regular Emacs is the current version and I very rarely use
> > emacs-next because I started Emacs with 23 therefore 24 was already a
> > so-nice improvement. :-))
>
> It does make sense. For those who would like to see our base Emacs
> package be updated to emacs-next, we need to iron out all the packages
> currently failing to build with it. It is easy to try, by modifying
> slightly a local Guix checkout:
>
> --8<---------------cut here---------------start------------->8---
> 1 file changed, 1 insertion(+), 1 deletion(-)
> guix/build-system/emacs.scm | 2 +-
>
> modified guix/build-system/emacs.scm
> @@ -52,7 +52,7 @@
> "Return the default Emacs package."
> ;; Lazily resolve the binding to avoid a circular dependency.
> (let ((emacs-mod (resolve-interface '(gnu packages emacs))))
> - (module-ref emacs-mod 'emacs-minimal)))
> + (module-ref emacs-mod 'emacs-next)))
>
> (define* (lower name
> #:key source inputs native-inputs outputs system target
>
> --8<---------------cut here---------------end--------------->8---

What I propose simplifies because it avoids to recompile all Guix and
to use ./pre-inst-env.
Well, I do not know. It is an half-cooked proposal. :-)

And the added 'package-with-explicit-emacs' procedure allows to use
any Emacs as the VM, so for example, it could be cool to see what
happens with REmacs (which is not packaged but that's another story
:-)).
Or for example with Gccemacs.


All the best,
simon

ps:
Note that 'package-with-explicite-emacs' and
'package-with-explicit-python' should be refactored, another story.
:-)
From 4038b0c53d5066facceea3c159a6510fa8a625d6 Mon Sep 17 00:00:00 2001
From: zimoun <zimon.toutoune@gmail.com>
Date: Sun, 7 Jun 2020 11:07:08 +0200
Subject: [PATCH] DRAFT: build-system: emacs: Add new
'package-with-emacs-next'procedure.

* guix/build-system/emacs.scm: Add 'default-emacs-next'.
* guix/build-system/emacs.scm: Add 'package-with-emacs-next'.
---
guix/build-system/emacs.scm | 66 +++++++++++++++++++++++++++++++++++++
1 file changed, 66 insertions(+)

Toggle diff (92 lines)
diff --git a/guix/build-system/emacs.scm b/guix/build-system/emacs.scm
index ef6d1b3397..8732678dca 100644
--- a/guix/build-system/emacs.scm
+++ b/guix/build-system/emacs.scm
@@ -1,5 +1,6 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2015 Federico Beffa <beffa@fbengineering.ch>
+;;; Copyright © 2020 Simon Tournier <zimon.toutoune@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -29,6 +30,7 @@
#:use-module (ice-9 match)
#:use-module (srfi srfi-26)
#:export (%emacs-build-system-modules
+ package-with-emacs-next
emacs-build
emacs-build-system)
#:re-export (%default-include ;for convenience
@@ -54,6 +56,70 @@
(let ((emacs-mod (resolve-interface '(gnu packages emacs))))
(module-ref emacs-mod 'emacs-minimal)))
+(define (default-emacs-next)
+ "Return the default Emacs-next package."
+ (let ((emacs-mod (resolve-interface '(gnu packages emacs))))
+ (module-ref emacs-mod 'emacs-next)))
+
+(define* (package-with-explicit-emacs emacs old-prefix new-prefix
+ #:key variant-property)
+ "Return a procedure of one argument, P. The procedure creates a package with
+the same fields as P, which is assumed to use EMACS-BUILD-SYSTEM, such that
+it is compiled with EMACS instead. The inputs are changed recursively
+accordingly. If the name of P starts with OLD-PREFIX, this is replaced by
+NEW-PREFIX; otherwise, NEW-PREFIX is prepended to the name.
+
+When VARIANT-PROPERTY is present, it is used as a key to search for
+pre-defined variants of this transformation recorded in the 'properties' field
+of packages. The property value must be the promise of a package. This is a
+convenient way for package writers to force the transformation to use
+pre-defined variants."
+ (define package-variant
+ (if variant-property
+ (lambda (package)
+ (assq-ref (package-properties package)
+ variant-property))
+ (const #f)))
+
+ (define (transform p)
+ (cond
+ ;; If VARIANT-PROPERTY is present, use that.
+ ((package-variant p)
+ => force)
+
+ ;; Otherwise build the new package object graph.
+ ((eq? (package-build-system p) emacs-build-system)
+ (package
+ (inherit p)
+ (location (package-location p))
+ (name (let ((name (package-name p)))
+ (string-append new-prefix
+ (if (string-prefix? old-prefix name)
+ (substring name
+ (string-length old-prefix))
+ name))))
+ (arguments
+ (let ((emacs (if (promise? emacs)
+ (force emacs)
+ emacs)))
+ (ensure-keyword-arguments (package-arguments p)
+ `(#:emacs ,emacs))))))
+ (else p)))
+
+ (define (cut? p)
+ (or (not (eq? (package-build-system p) emacs-build-system))
+ (package-variant p)))
+
+ (package-mapping transform cut?))
+
+(define package-with-emacs-next
+ ;; Note: delay call to 'default-emacs-next' until after the 'arguments' field
+ ;; of packages is accessed to avoid a circular dependency when evaluating
+ ;; the top-level of (gnu packages emacs).
+ (package-with-explicit-emacs (delay (default-emacs-next))
+ "emacs-" "emacs-next-"
+ #:variant-property 'emacs-next-variant))
+
(define* (lower name
#:key source inputs native-inputs outputs system target
(emacs (default-emacs))
--
2.26.2
M
M
Maxim Cournoyer wrote on 17 Jun 2020 06:34
(name . zimoun)(address . zimon.toutoune@gmail.com)
87zh92e2eo.fsf@gmail.com
Hello Simon!

Sorry for my delayed answer.

zimoun <zimon.toutoune@gmail.com> writes:

Toggle quote (46 lines)
> Dear Maxim,
>
> On Sun, 7 Jun 2020 at 06:39, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>
>> Some people have been adding emacs-next-something packages (IIRC); I
>> think it's OK for the big, complicated packages that need effort to
>> port, but otherwise I wouldn't like seeing this happening for all
>> packages.
>
> I agree. I am not suggesting to duplicate all the packages with
> 'emacs-next-something'. There is already enough to do with the
> current ones. :-)
>
>
>> > Well, I am not suggesting to duplicate all the Emacs packages with
>> > something like 'emacs-next-<package>' because it is too much. I am
>> > suggesting to provide 'package-with-emacs-next' and then for example
>> > in my manifest file I would use this new procedure to generate
>> > on-the-fly these next packages; as an expert Emacs mode.
>>
>> That sounds like a good idea; provide a way for users to rewrite their
>> package at the level of their manifest file (which is already possible
>> IIUC).
>
> I propose to provide 'package-with-emacs-next' for the people in the
> experimental mood. :-) For example, the manifest looks like:
>
> (use-modules (guix build-system emacs)
> (gnu packages emacs)
> (gnu packages emacs-xyz))
>
> (packages->manifest
> (cons emacs-next
> (map
> package-with-emacs-next
> (list
> emacs-lua-mode
> emacs-magit))))
>
> Then the expert uses it with:
>
> guix package -m manifest.scm
>
> Well, the attached patch does that. And maybe, an entry to the
> Cookbook could be worth.

That's really nice! Thank you for providing it. I've tried it in my
manifest, by stitching a couple manifests objects together
`concatenate-manifests' like so:

Toggle snippet (22 lines)
(concatenate-manifests
(list
;;; Emacs packages.
(packages->manifest
(cons emacs-next
(map package-with-emacs-next
(map specification->package
'("emacs-auctex"
"emacs-bash-completion"
[...]
"emacs-yasnippet"
"emacs-yasnippet-snippets")))))

;; Other software.
(specifications->manifest
'("adb"
[...]
"arc-icon-theme"
"arc-theme"
...))))

And after a couple fixes on master, I was able to build my profile with
my Emacs packages collection built against Emacs 27! I'm now having
some issues due to the apparent renaming of the generated autoload
files. I haven't had the time to look for a fix yet. It breaks at
least Helm (and probably others), as it cannot find its own autoload
file.

next-helm-autoloads.el ->
/gnu/store/fnwalhxi94fhr8h2dfg602zd9plarwx0-emacs-next-helm-3.6.2/share/emacs/site-lisp/next-helm-autoloads.el

(instead of helm-autoloads.el)

Toggle quote (4 lines)
> Note that 'package-with-explicite-emacs' and
> 'package-with-explicit-python' should be refactored, another story.
> :-)

I wholly agree! It seems these have much in common. Perhaps (guix
packages) could be a new home for the factored out bits.

To be continued!

Maxim
M
M
Maxim Cournoyer wrote on 1 Sep 2020 20:53
control message for bug #41732
(address . control@debbugs.gnu.org)
87v9gxpbug.fsf@gmail.com
retitle 41732 Implement a wrapper so users can build the Emacs packages using a version of their choosing
quit
Z
Z
zimoun wrote on 16 Sep 2020 16:51
Re: bug#41732: New ’package-with-emacs-next ’ procedure
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87v9gdpyfq.fsf_-_@gmail.com
Dear Maxim,

On Wed, 17 Jun 2020 at 00:34, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
Toggle quote (4 lines)
> zimoun <zimon.toutoune@gmail.com> writes:

> Sorry for my delayed answer.

Sorry, I have missed your answer.


Toggle quote (59 lines)
>> I propose to provide 'package-with-emacs-next' for the people in the
>> experimental mood. :-) For example, the manifest looks like:
>>
>> (use-modules (guix build-system emacs)
>> (gnu packages emacs)
>> (gnu packages emacs-xyz))
>>
>> (packages->manifest
>> (cons emacs-next
>> (map
>> package-with-emacs-next
>> (list
>> emacs-lua-mode
>> emacs-magit))))
>>
>> Then the expert uses it with:
>>
>> guix package -m manifest.scm
>>
>> Well, the attached patch does that. And maybe, an entry to the
>> Cookbook could be worth.
>
> That's really nice! Thank you for providing it. I've tried it in my
> manifest, by stitching a couple manifests objects together
> `concatenate-manifests' like so:
>
> (concatenate-manifests
> (list
> ;;; Emacs packages.
> (packages->manifest
> (cons emacs-next
> (map package-with-emacs-next
> (map specification->package
> '("emacs-auctex"
> "emacs-bash-completion"
> [...]
> "emacs-yasnippet"
> "emacs-yasnippet-snippets")))))
>
> ;; Other software.
> (specifications->manifest
> '("adb"
> [...]
> "arc-icon-theme"
> "arc-theme"
> ...))))
>
> And after a couple fixes on master, I was able to build my profile with
> my Emacs packages collection built against Emacs 27! I'm now having
> some issues due to the apparent renaming of the generated autoload
> files. I haven't had the time to look for a fix yet. It breaks at
> least Helm (and probably others), as it cannot find its own autoload
> file.
>
> next-helm-autoloads.el ->
> /gnu/store/fnwalhxi94fhr8h2dfg602zd9plarwx0-emacs-next-helm-3.6.2/share/emacs/site-lisp/next-helm-autoloads.el
>
> (instead of helm-autoloads.el)

What do you think to add this ’package-with-emacs-next’?
It should help when upgrading Emacs: detect which packages break, report
upstream or fix, etc. Helm is a good example.

Couple of days before emacs-next becomes the new emacs, an announcement
of the coming soon switch on guix-devel and a call for testing and
report issues.

If it appears to you a good idea, I can rebase the patch and resubmit
it, and add an example to the Cooking book.


Toggle quote (7 lines)
>> Note that 'package-with-explicite-emacs' and
>> 'package-with-explicit-python' should be refactored, another story.
>> :-)
>
> I wholly agree! It seems these have much in common. Perhaps (guix
> packages) could be a new home for the factored out bits.

The story is long. :-)

There is ’package-with-explicit-python’ and also
’package-with-explicit-ocaml’, I would like to have
’package-with-explicit-c-compiler’ too to rebuild C packages with any
version of GCC or even Clang. One way to achieve is “package parameter”
but the consensus on the topic has not been reached. Therefore
’package-with-explicit-<name-it>’ seems a working short term workaround
waiting something more “elegant“. But yeah, maybe the 3
’package-with-explicit-{python,ocaml,emacs}’ could be refactored; I do
not know.


All the best,
simon
Z
Z
zimoun wrote on 26 Sep 2020 18:12
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
868scwtt34.fsf@gmail.com
Dear,

On Wed, 16 Sep 2020 at 16:51, zimoun <zimon.toutoune@gmail.com> wrote:

Toggle quote (22 lines)
>>> I propose to provide 'package-with-emacs-next' for the people in the
>>> experimental mood. :-) For example, the manifest looks like:
>>>
>>> (use-modules (guix build-system emacs)
>>> (gnu packages emacs)
>>> (gnu packages emacs-xyz))
>>>
>>> (packages->manifest
>>> (cons emacs-next
>>> (map
>>> package-with-emacs-next
>>> (list
>>> emacs-lua-mode
>>> emacs-magit))))
>>>
>>> Then the expert uses it with:
>>>
>>> guix package -m manifest.scm
>>>
>>> Well, the attached patch does that. And maybe, an entry to the
>>> Cookbook could be worth.

I withdraw the patch proposal since the patch set #43578 [1] fulfills
the request. Now, for recompiling all the Emacs packages of one
manifest.scm file with the emacs-next package (changing the Emacs VM),
it is as easy as:

Toggle snippet (3 lines)
guix build -m manifest.scm --with-input=emacs-minimal=emacs-next

Before closing, what do you think adding something in the manual or the
cookbook will be worth? It could be useful when switching the Emacs
version –– for example the last 26 to 27.


All the best,
simon
N
N
Nicolas Goaziou wrote on 26 Sep 2020 18:53
(name . zimoun)(address . zimon.toutoune@gmail.com)
87blhs5vjl.fsf@nicolasgoaziou.fr
Hello,

zimoun <zimon.toutoune@gmail.com> writes:

Toggle quote (9 lines)
> I withdraw the patch proposal since the patch set #43578 [1] fulfills
> the request. Now, for recompiling all the Emacs packages of one
> manifest.scm file with the emacs-next package (changing the Emacs VM),
> it is as easy as:
>
> --8<---------------cut here---------------start------------->8---
> guix build -m manifest.scm --with-input=emacs-minimal=emacs-next
> --8<---------------cut here---------------end--------------->8---

Some Emacs packages rely on emacs package, not on emacs-minimal. IIUC,
the command above could give surprising results in this case. Maybe the
documentation/cookbook could warn about this caveat.

Regards,
--
Nicolas Goaziou
M
M
Maxim Cournoyer wrote on 27 Sep 2020 05:45
(name . Nicolas Goaziou)(address . mail@nicolasgoaziou.fr)
874knjsx16.fsf@gmail.com
Hi Nicolas,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

Toggle quote (17 lines)
> Hello,
>
> zimoun <zimon.toutoune@gmail.com> writes:
>
>> I withdraw the patch proposal since the patch set #43578 [1] fulfills
>> the request. Now, for recompiling all the Emacs packages of one
>> manifest.scm file with the emacs-next package (changing the Emacs VM),
>> it is as easy as:
>>
>> --8<---------------cut here---------------start------------->8---
>> guix build -m manifest.scm --with-input=emacs-minimal=emacs-next
>> --8<---------------cut here---------------end--------------->8---
>
> Some Emacs packages rely on emacs package, not on emacs-minimal. IIUC,
> the command above could give surprising results in this case. Maybe the
> documentation/cookbook could warn about this caveat.

Perhaps then,

Toggle snippet (4 lines)
guix build -m manifest.scm --with-input=emacs-minimal=emacs-next \
--with-input=emacs=emacs-next

I haven't tried myself.

Maxim
N
N
Nicolas Goaziou wrote on 27 Sep 2020 11:00
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
877dsf61ch.fsf@nicolasgoaziou.fr
Hello,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (7 lines)
> Perhaps then,
>
> --8<---------------cut here---------------start------------->8---
> guix build -m manifest.scm --with-input=emacs-minimal=emacs-next \
> --with-input=emacs=emacs-next
> --8<---------------cut here---------------end--------------->8---

Possibly. And then Magit uses emacs-no-x as an input, so we may need to
also add --with-input=emacs-no-x=emacs-next to the command.

I'm just pointing out that the process is not as straightforward as it
might seem. So, it doesn't sound right to simply suggest

guix build -m manifest.scm --with-input=emacs-minimal=emacs-next

in the manual/cookbook without caution.

Or maybe `package-with-emacs-next' could be more high-level, and handle
all of these cases. I don't know.

Regards,
--
Nicolas Goaziou
M
M
Maxim Cournoyer wrote on 28 Sep 2020 05:03
(name . Nicolas Goaziou)(address . mail@nicolasgoaziou.fr)
878scur4ab.fsf@gmail.com
Hello,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

Toggle quote (13 lines)
> Possibly. And then Magit uses emacs-no-x as an input, so we may need to
> also add --with-input=emacs-no-x=emacs-next to the command.
>
> I'm just pointing out that the process is not as straightforward as it
> might seem. So, it doesn't sound right to simply suggest
>
> guix build -m manifest.scm --with-input=emacs-minimal=emacs-next
>
> in the manual/cookbook without caution.
>
> Or maybe `package-with-emacs-next' could be more high-level, and handle
> all of these cases. I don't know.

Yeah, that would probably me more convenient/robust to use, if it was
covering for all the weird cases one might forget. I'd still be in
favor of having such a helper procedure.

Maxim
Z
Z
zimoun wrote on 28 Sep 2020 10:29
Re: bug#41732: New ’package-with-emacs-next’ pro cedure
(name . Nicolas Goaziou)(address . mail@nicolasgoaziou.fr)
CAJ3okZ1xKHE18Z-scxGGNs-4Ea5yOUwhtcx7xbHybCVTbB3C5g@mail.gmail.com
Hi,

Thank you for your insights.

On Sun, 27 Sep 2020 at 15:12, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

Toggle quote (8 lines)
> > --8<---------------cut here---------------start------------->8---
> > guix build -m manifest.scm --with-input=emacs-minimal=emacs-next \
> > --with-input=emacs=emacs-next
> > --8<---------------cut here---------------end--------------->8---
>
> Possibly. And then Magit uses emacs-no-x as an input, so we may need to
> also add --with-input=emacs-no-x=emacs-next to the command.

[...]

Toggle quote (3 lines)
> Or maybe `package-with-emacs-next' could be more high-level, and handle
> all of these cases. I don't know.

I am not familiar with the Emacs build system. Do the packages need
different flavors of the Emacs VM to be byte-compiled?
For example, the package emacs-magit drags emacs-no-x because of
emacs-libgit, why is emacs-minimal not enough here?

Well, the emacs-build-system depends (implicitly) on emacs-minimal,
only. And the initial patch `package-with-emacs-next' was changing
this, only. However, the package emacs-libgit is cmake-build-system
and the package emacs-no-x is an explicit dependency; which is another
story. :-)

Therefore, the `package-with-emacs-next' could replace the Emacs used
by the build system (emacs-minimal -> emacs-next-minimal) and also
traverse all the graph of dependencies and replace all the Emacs
variants (emacs-{minimal,xwidgets,no-x,no-x-toolkit,wide-int}) in
gnu/packages/emacs.scm by the package emacs-next. I am not sure it
will work. Maybe the Emacs variants should also be rebuilt inheriting
from emacs-next instead of emacs. WDYT?

Does it make sense?


All the best,
simon
?
Your comment

Commenting via the web interface is currently disabled.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 41732
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