GNU bug report logs - #41732
Implement a wrapper so users can build the Emacs packages using a version of their choosing

Previous Next

Full log

View this message in rfc822 format

From: zimoun <zimon.toutoune <at> gmail.com>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 41732 <at> debbugs.gnu.org, Fredrik Salomonsson <plattfot <at> gmail.com>, Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Subject: bug#41732: New ’package-with-emacs-next’ procedure
Date: Wed, 16 Sep 2020 16:51:21 +0200

Dear Maxim,

On Wed, 17 Jun 2020 at 00:34, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:
> zimoun <zimon.toutoune <at> gmail.com> writes:

> Sorry for my delayed answer.

Sorry, I have missed your answer.


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


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

Previous Next

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