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

OpenSubmitted by Fredrik Salomonsson.
Details
5 participants
  • Fredrik Salomonsson via web
  • Nicolas Goaziou
  • Maxim Cournoyer
  • Fredrik Salomonsson
  • zimoun
Owner
unassigned
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'mgetting this error"Error (use-package): lua-mode/:catch: Unknown rx form ‘symbol’"
It works when I let emacs download it from melpa. I tried updatingemacs-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 compilethe 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.
My emacs config is here: https://github.com/plattfot/dotemacs/tree/emacs27I've attached the backtrace and the patch for the latest emacs-lua-mode.
Thanks
[1] https://github.com/immerrr/lua-mode/issues/153-- s/Fred[re]+i[ck]+/Fredrik/g
Attachment: file
From 1ef949ea0a9bdec2bdf42c0314b8e8e01acff72d Mon Sep 17 00:00:00 2001From: Fredrik Salomonsson <plattfot@gmail.com>Date: Fri, 5 Jun 2020 19:39:37 -0700Subject: [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.scmindex 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
https://github.com/immerrr/lua-mode/issues/155
You may be right. Files byte-compiled with Emacs 26 may not becompatible 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 Emacstoolchain 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 couldtry 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 packagesare byte-compiled with the current Emacs. Therefore, "guix installemacs-next emacs-foo" and then "M-x foo" works by luck -- well becausethe 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 withsomething like 'emacs-next-<package>' because it is too much. I amsuggesting to provide 'package-with-emacs-next' and then for examplein my manifest file I would use this new procedure to generateon-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 useemacs-next because I started Emacs with 23 therefore 24 was already aso-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 thatemacs-something works with emacs-next unless it was packaged to becompiled 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); Ithink it's OK for the big, complicated packages that need effort toport, but otherwise I wouldn't like seeing this happening for allpackages.
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 theirpackage at the level of their manifest file (which is already possibleIIUC).
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 Emacspackage be updated to emacs-next, we need to iron out all the packagescurrently failing to build with it. It is easy to try, by modifyingslightly 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 thecurrent 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 theexperimental 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 theCookbook 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 andto 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 useany Emacs as the VM, so for example, it could be cool to see whathappens 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 2001From: zimoun <zimon.toutoune@gmail.com>Date: Sun, 7 Jun 2020 11:07:08 +0200Subject: [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.scmindex 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 mymanifest, 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 withmy Emacs packages collection built against Emacs 27! I'm now havingsome issues due to the apparent renaming of the generated autoloadfiles. I haven't had the time to look for a fix yet. It breaks atleast Helm (and probably others), as it cannot find its own autoloadfile.
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 (guixpackages) 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 choosingquit
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, reportupstream or fix, etc. Helm is a good example.
Couple of days before emacs-next becomes the new emacs, an announcementof the coming soon switch on guix-devel and a call for testing andreport issues.
If it appears to you a good idea, I can rebase the patch and resubmitit, 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 anyversion 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 workaroundwaiting something more “elegant“. But yeah, maybe the 3’package-with-explicit-{python,ocaml,emacs}’ could be refactored; I donot 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] fulfillsthe request. Now, for recompiling all the Emacs packages of onemanifest.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 thecookbook will be worth? It could be useful when switching the Emacsversion –– for example the last 26 to 27.
[1] http://issues.guix.gnu.org/issue/43578
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 thedocumentation/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 toalso add --with-input=emacs-no-x=emacs-next to the command.
I'm just pointing out that the process is not as straightforward as itmight 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 handleall 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 wascovering for all the weird cases one might forget. I'd still be infavor 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 needdifferent flavors of the Emacs VM to be byte-compiled?For example, the package emacs-magit drags emacs-no-x because ofemacs-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 changingthis, only. However, the package emacs-libgit is cmake-build-systemand the package emacs-no-x is an explicit dependency; which is anotherstory. :-)
Therefore, the `package-with-emacs-next' could replace the Emacs usedby the build system (emacs-minimal -> emacs-next-minimal) and alsotraverse all the graph of dependencies and replace all the Emacsvariants (emacs-{minimal,xwidgets,no-x,no-x-toolkit,wide-int}) ingnu/packages/emacs.scm by the package emacs-next. I am not sure itwill work. Maybe the Emacs variants should also be rebuilt inheritingfrom 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 email to 41732@debbugs.gnu.org