[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#41732: New ’package-with-emacs-next’ procedure

From: zimoun
Subject: bug#41732: New ’package-with-emacs-next’ procedure
Date: Wed, 16 Sep 2020 16:51:21 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Dear Maxim,

On Wed, 17 Jun 2020 at 00:34, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
> zimoun <zimon.toutoune@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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]