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