bug#48331: Emacs' describe-package doesn't work for packages managed by guix
On 2021-12-03 21:46, Liliana Marie Prikler wrote: > At long last, I'm pushing the patch to keep -pkg.el files as well as to > load them from guix-emacs during package-initialize. I'll hereby be > closing this bug. Andrew, if you wish to write a phase that adds such > a file for the packages currently lacking them, I'm pretty sure we can > do with a new bug number for that :) I implemented this phase in issues.guix.gnu.org/52388, I have it applied to my local guix fork and I didn't notice any issues with it, however, emacs packages built without emacs-build-system will require tweaking. Everyone reading this thread can jump to [1] and check it out =) [1]: The mail thread id is 871r2mrleb@trop.in > > Thanks everyone involved for your help and patience. Cheers > -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
On 2021-12-03 21:46, Liliana Marie Prikler wrote: > At long last, I'm pushing the patch to keep -pkg.el files as well as to > load them from guix-emacs during package-initialize. I'll hereby be > closing this bug. Andrew, if you wish to write a phase that adds such > a file for the packages currently lacking them, I'm pretty sure we can > do with a new bug number for that :) > > Thanks everyone involved for your help and patience. Cheers > Thank you very much for applying this change!) -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
At long last, I'm pushing the patch to keep -pkg.el files as well as to load them from guix-emacs during package-initialize. I'll hereby be closing this bug. Andrew, if you wish to write a phase that adds such a file for the packages currently lacking them, I'm pretty sure we can do with a new bug number for that :) Thanks everyone involved for your help and patience. Cheers
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
> > In other words, no particular thought was given to -pkg.el. It was > > simply dropped along with many other files. So, if consensus is > > reachedthat keeping -pkg.el is a good idea, there is no reason to not > > do that. > Thanks for clearing that up. In that case, I don't have any qualms > about including them either. Cool, seems we can get -pkg.el files back. > Multi-profile Emacs should be supported, but this also breaks on > foreign distros with foreign distro ELPA. Again, hacking variables is > not the solution (and even if it was, it'd be better to patch the emacs > default value, not that this is a good idea either). Yep, the last snippet supports multi-profile Emacs. Installing packages for Emacs via a few different package manager sounds like a very bad practice) I agree that current implementation with updating variables isn't perfect and it doesn't cover the use case, which I expect to be rare (packages from Guix will be listed in list-packages, files from foreign distro PM won't). I can dive into package.el implementation and spend some time next week providing a different workaround. BTW, can you remind me why we do not place packages under site-lisp/elpa/NAME-VERSION? It seems almost the same as site-lisp/NAME-VERSION, but everything related to describe-package and other functions will work out of the box. This way it will work even with a foreign distro use case.
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
Hello, Leo Prikler writes: > Am Donnerstag, den 20.05.2021, 15:24 +0300 schrieb Andrew Tropin: >> > > In other words, no particular thought was given to -pkg.el. It >> > > was >> > > simply dropped along with many other files. So, if consensus is >> > > reachedthat keeping -pkg.el is a good idea, there is no reason to >> > > not >> > > do that. >> > Thanks for clearing that up. In that case, I don't have any qualms >> > about including them either. >> >> Cool, seems we can get -pkg.el files back. > Yes, we can. I'm late, but I think it's OK to have those *-pkg.el files installed, if they are useful. [...] >> BTW, can you remind me why we do not place packages under >> site-lisp/elpa/NAME-VERSION? It seems almost the same as >> site-lisp/NAME-VERSION, but everything related to describe-package >> and other functions will work out of the box. This way it will work >> even with a foreign distro use case. > Again, Guix is not ELPA and calling it ELPA would be misleading. As > for why we don't put stuff in any other site-lisp/ directory, e.g. > site-lisp/guix.d/NAME-VERSION, doing that led to rather tricky issues, > which is why we've decided to use site-lisp "directly". The current > way of handling things is a bit of a compromise. It gives you per- > package directories like ELPA, but unlike ELPA can easily be handled at > Emacs startup. If you are interested in an alternate view of the world, with the benefits and drawbacks of integrating with package.el to provide packages autoloading in Guix, you may be interested in studying the abandoned https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45316. The packages are loaded by the package.el library via (package-initialize). The main drawback (that was deemed inconvenient enough to not go ahead with this scheme) is summarized in the introductory message: Parting with a directly usable EMACSLOADPATH means that site-start.el *must* run for packages to appear in the load-path; that means for running a test suite, the -Q or --quick Emacs options cannot be used, since it implies --no-site-file. HTH, Maxim
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
Am Donnerstag, den 20.05.2021, 15:24 +0300 schrieb Andrew Tropin: > > > In other words, no particular thought was given to -pkg.el. It > > > was > > > simply dropped along with many other files. So, if consensus is > > > reachedthat keeping -pkg.el is a good idea, there is no reason to > > > not > > > do that. > > Thanks for clearing that up. In that case, I don't have any qualms > > about including them either. > > Cool, seems we can get -pkg.el files back. Yes, we can. > > Multi-profile Emacs should be supported, but this also breaks on > > foreign distros with foreign distro ELPA. Again, hacking variables > > is not the solution (and even if it was, it'd be better to patch > > the emacs default value, not that this is a good idea either). > > Yep, the last snippet supports multi-profile Emacs. While that's better, I still don't think it's sufficient. > Installing packages for Emacs via a few different package manager > sounds like a very bad practice) I agree that current implementation > with updating variables isn't perfect and it doesn't cover the use > case, which I expect to be rare (packages from Guix will be listed in > list-packages, files from foreign distro PM won't). I can dive into > package.el implementation and spend some time next week providing a > different workaround. I think this is common practice on other distros. For example your system provides auctex, but it doesn't provide dash.el. What do you do? Install it through ELPA. Now let's say, you have Guix installed. Guix provides packages for some of ELPA, but not what you want. You could hack together a Guix package based on the ELPA importer, but perhaps upstream is slow in accepting it or perhaps you've fetched the package from a shady source, that Guix won't accept. So you have foreign distro system packages + Guix + personal ELPA. As far as getting Guix packages to work without affecting the rest of package.el or user configuration, I think an advice, that runs after package-load-all-descriptors might be necessary. As for the candidates to check for this advice, you can read all subdirs.el files you find inside load-path. When they're formatted (normal-top-level-add-to-load-path (list P1 ... PN)) they were likely added by Guix (even if not, one should probably consider them important) and P1 ... PN should be scanned for descriptors. > BTW, can you remind me why we do not place packages under > site-lisp/elpa/NAME-VERSION? It seems almost the same as > site-lisp/NAME-VERSION, but everything related to describe-package > and other functions will work out of the box. This way it will work > even with a foreign distro use case. Again, Guix is not ELPA and calling it ELPA would be misleading. As for why we don't put stuff in any other site-lisp/ directory, e.g. site-lisp/guix.d/NAME-VERSION, doing that led to rather tricky issues, which is why we've decided to use site-lisp "directly". The current way of handling things is a bit of a compromise. It gives you per- package directories like ELPA, but unlike ELPA can easily be handled at Emacs startup.
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
Am Donnerstag, den 20.05.2021, 16:09 +0530 schrieb Arun Isaac: > > > [Adding Arun Isaac to CC. Their commit d8796851 is the first one > > > to > > > drop -pkg.el, but without explanation.] > > > > Commit d8796851 was an attempt to not install too many unnecessary > > files > > and be closer to how MELPA packaged emacs packages. See > > https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00274.html > > for > > the detailed discussion. > > In other words, no particular thought was given to -pkg.el. It was > simply dropped along with many other files. So, if consensus is > reachedthat keeping -pkg.el is a good idea, there is no reason to not > do that. Thanks for clearing that up. In that case, I don't have any qualms about including them either. Cheers!
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
> That looks like it'd mess with people's installed ELPA packages. In > general, hacks based on package-directory-list don't feel very stable. If you talk about ~/.emacs.d/elpa, it won't, because there is a separate package-user-dir variable for that. The problem can arise if we have emacs installed in a few profiles, I'm not sure if it is a good idea to do so, but it is possible, in such a case we will have a few items in the package-directory-list. A fix for that: (setq package-directory-list (mapcar (apply-partially 'string-remove-suffix "/elpa") package-directory-list))) > Also, this seems to rely on us not deleting the -pkg.el, but probably > won't work for packages, that don't ship it, e.g. emacs-howm. It's true, but it seems relatively easy to implement a build phase, which will generate -pgk.el in case it is missing.
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
>> [Adding Arun Isaac to CC. Their commit d8796851 is the first one to >> drop -pkg.el, but without explanation.] > > Commit d8796851 was an attempt to not install too many unnecessary files > and be closer to how MELPA packaged emacs packages. See > https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00274.html for > the detailed discussion. In other words, no particular thought was given to -pkg.el. It was simply dropped along with many other files. So, if consensus is reached that keeping -pkg.el is a good idea, there is no reason to not do that. Cheers! signature.asc Description: PGP signature
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
> [Adding Arun Isaac to CC. Their commit d8796851 is the first one to > drop -pkg.el, but without explanation.] Commit d8796851 was an attempt to not install too many unnecessary files and be closer to how MELPA packaged emacs packages. See https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00274.html for the detailed discussion. Cheers! signature.asc Description: PGP signature
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
Am Donnerstag, den 20.05.2021, 13:01 +0300 schrieb Andrew Tropin: > > That looks like it'd mess with people's installed ELPA > > packages. In general, hacks based on package-directory-list don't > > feel very stable. > > If you talk about ~/.emacs.d/elpa, it won't, because there is a > separate package-user-dir variable for that. > > The problem can arise if we have emacs installed in a few profiles, > I'm not sure if it is a good idea to do so, but it is possible, in > such a case we will have a few items in the package-directory- > list. A fix for that: > > (setq package-directory-list > (mapcar (apply-partially 'string-remove-suffix "/elpa") > package-directory-list))) Multi-profile Emacs should be supported, but this also breaks on foreign distros with foreign distro ELPA. Again, hacking variables is not the solution (and even if it was, it'd be better to patch the emacs default value, not that this is a good idea either). > > Also, this seems to rely on us not deleting the -pkg.el, but > > probably won't work for packages, that don't ship it, e.g. emacs- > > howm. > > It's true, but it seems relatively easy to implement a build phase, > which will generate -pgk.el in case it is missing. Generating our own -pkg.el should work, still waiting for Maxim or Arun on a statement as to why we exclude it. *Always* generating a -pkg.el (disregarding the upstream one if it exists) might further be a reasonable thing to do if we decide, that those -pkg.el files are useful. Regards, Leo
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
That looks like it'd mess with people's installed ELPA packages. In general, hacks based on package-directory-list don't feel very stable. Consider writing a function similar in nature to `package-load-all- descriptors' instead. Also, this seems to rely on us not deleting the -pkg.el, but probably won't work for packages, that don't ship it, e.g. emacs-howm. [Adding Arun Isaac to CC. Their commit d8796851 is the first one to drop -pkg.el, but without explanation.] Am Mittwoch, den 19.05.2021, 20:58 +0300 schrieb Andrew Tropin: > From: Andrew Tropin > Date: Wed, 19 May 2021 20:44:22 +0300 > Subject: [PATCH] guix: build: emacs-build-system: Make package.el > aware of > guix packages > > After updating the package-directory-list variable, functions like > list-packages, > describe-package become aware of packages installed by guix. > > --- > This code is getting work done, but I'm not a very experienced elisp > developer, so > please review it thoroughly. > > gnu/packages/aux-files/emacs/guix-emacs.el | 10 ++ > guix/build/emacs-build-system.scm | 2 +- > 2 files changed, 11 insertions(+), 1 deletion(-) > > diff --git a/gnu/packages/aux-files/emacs/guix-emacs.el > b/gnu/packages/aux-files/emacs/guix-emacs.el > index ca9146c535..4aa4220cda 100644 > --- a/gnu/packages/aux-files/emacs/guix-emacs.el > +++ b/gnu/packages/aux-files/emacs/guix-emacs.el > @@ -58,6 +58,16 @@ The files in the list do not have extensions (.el, > .elc)." > (load f 'noerror)) >autoloads))) > > + > +(require 'package) > + > +;; Set `package-directory-list' to the value without elpa/ suffix > +;; to match the structure of site-lisp directory of guix's emacs > +;; build system. > +;;;###autoload > +(setq package-directory-list > + (list (string-remove-suffix "/elpa" (car package-directory- > list > + > (provide 'guix-emacs) > > ;;; guix-emacs.el ends here > diff --git a/guix/build/emacs-build-system.scm > b/guix/build/emacs-build-system.scm > index e41e9a6595..7565b9a422 100644 > --- a/guix/build/emacs-build-system.scm > +++ b/guix/build/emacs-build-system.scm > @@ -53,7 +53,7 @@ > > ;; These are the default inclusion/exclusion regexps for the install > phase. > (define %default-include '("^[^/]*\\.el$" "^[^/]*\\.info$" > "^doc/.*\\.info$")) > -(define %default-exclude '("^\\.dir-locals\\.el$" "-pkg\\.el$" > +(define %default-exclude '("^\\.dir-locals\\.el$" > "^[^/]*tests?\\.el$")) > > (define gnu:unpack (assoc-ref gnu:%standard-phases 'unpack))
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
From: Andrew Tropin Date: Wed, 19 May 2021 20:44:22 +0300 Subject: [PATCH] guix: build: emacs-build-system: Make package.el aware of guix packages After updating the package-directory-list variable, functions like list-packages, describe-package become aware of packages installed by guix. --- This code is getting work done, but I'm not a very experienced elisp developer, so please review it thoroughly. gnu/packages/aux-files/emacs/guix-emacs.el | 10 ++ guix/build/emacs-build-system.scm | 2 +- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/gnu/packages/aux-files/emacs/guix-emacs.el b/gnu/packages/aux-files/emacs/guix-emacs.el index ca9146c535..4aa4220cda 100644 --- a/gnu/packages/aux-files/emacs/guix-emacs.el +++ b/gnu/packages/aux-files/emacs/guix-emacs.el @@ -58,6 +58,16 @@ The files in the list do not have extensions (.el, .elc)." (load f 'noerror)) autoloads))) + +(require 'package) + +;; Set `package-directory-list' to the value without elpa/ suffix +;; to match the structure of site-lisp directory of guix's emacs +;; build system. +;;;###autoload +(setq package-directory-list + (list (string-remove-suffix "/elpa" (car package-directory-list + (provide 'guix-emacs) ;;; guix-emacs.el ends here diff --git a/guix/build/emacs-build-system.scm b/guix/build/emacs-build-system.scm index e41e9a6595..7565b9a422 100644 --- a/guix/build/emacs-build-system.scm +++ b/guix/build/emacs-build-system.scm @@ -53,7 +53,7 @@ ;; These are the default inclusion/exclusion regexps for the install phase. (define %default-include '("^[^/]*\\.el$" "^[^/]*\\.info$" "^doc/.*\\.info$")) -(define %default-exclude '("^\\.dir-locals\\.el$" "-pkg\\.el$" +(define %default-exclude '("^\\.dir-locals\\.el$" "^[^/]*tests?\\.el$")) (define gnu:unpack (assoc-ref gnu:%standard-phases 'unpack)) -- 2.31.1
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
> > Most other package managers seem to respect "infrastructure" provided > > by package.el. > I don't think that statement is well-supported by the data we have. Agree, that was an incorrect statement. I should have said something like: there are some popular tools like use-package configuration helper, Nix package manager, Spacemacs configuration framework, some elisp archives and probably something else, which utilize and follow package.el. Not all of them use package.el itself, but they follow conventions and describe-package help command and some other work correctly. > Why should we let ELPA dictate our layout? I have not even once tried > customizing package.el for actual use since I got Guix, because the > elpa importer is trivial. We don't have to. Actually, I'm very happy with the new (current) layout we have right now. I would say I find the following use case very confusing for newcomers: - Install emacs package via Guix. - Use built-in help C-h C-h, find C-h P. - Get it to work for built-in packages, but not for packages installed by Guix. - Get frustrated. I think we could avoid this at least in two ways: 1. Use elpa/ subdirectory. 2. Keep current structure, set package-directory-list to .../site-lisp instead of .../site-lisp/elpa by default. > Thus we're not trying to keep in line with any specific package > manager, we just need to make things work "with Emacs" in the sense > that packages installed via Guix should have working autoloads and one > should be able to (require ...) them. Yes, but at the same time I don't see reasons why not to implement one of two options above. We can get both: working autoloads and working built-in help function (+newcommers won't be so frustrated). Personally, I'm quite happy that packages got their own subdirectories and I'm fully satisfied with current state of it, but it would be cool if inexperienced users will be able to use at least built-in help commands for packages out of the box without additional configuration. Hope my original point is a little better worded now. -- Best regards, Andrew Tropin
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
> > M-x list-packages ;; Doesn't list treemacs > Let me recommend Emacs-Guix (aka. 'guix.el') as a superior alternative. > :-) Sure) Aware of it, cool tool. > I think it's fine that 'package.el' is unaware of Guix-managed software > and vice-versa. Yep, perfectly fine, but why not to make it aware, if it is relatively easy to achieve?)
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
Am Mittwoch, den 19.05.2021, 17:32 +0300 schrieb Andrew Tropin: > > > Most other package managers seem to respect "infrastructure" > > > provided by package.el. > > I don't think that statement is well-supported by the data we have. > > Agree, that was an incorrect statement. I should have said something > like: there are some popular tools like use-package configuration > helper, Nix package manager, Spacemacs configuration framework, some > elisp archives and probably something else, which utilize and follow > package.el. Not all of them use package.el itself, but they follow > conventions and describe-package help command and some other work > correctly. Is package.el really so well supported by all these tools? I might concede, that some of them don't throw away the package.el blurb like guix does, but other than that, I think you'd have a hard time stuffing a random git repo from use-package into package.el. Am I missing something? > > Why should we let ELPA dictate our layout? I have not even once > > tried customizing package.el for actual use since I got Guix, > > because the elpa importer is trivial. > > We don't have to. Actually, I'm very happy with the new (current) > layout we have right now. That's good :) > I would say I find the following use case very confusing for > newcomers: > - Install emacs package via Guix. > - Use built-in help C-h C-h, find C-h P. > - Get it to work for built-in packages, but not for packages > installed by Guix. > - Get frustrated. You mean Emacs newcomers? Tell me something new about the first-time Emacs experience :P > I think we could avoid this at least in two ways: > 1. Use elpa/ subdirectory. > 2. Keep current structure, set package-directory-list to .../site- > lisp instead of .../site-lisp/elpa by default. Neither sounds very pleasant, but does (2) even work? > > Thus we're not trying to keep in line with any specific package > > manager, we just need to make things work "with Emacs" in the sense > > that packages installed via Guix should have working autoloads and > > one should be able to (require ...) them. > > Yes, but at the same time I don't see reasons why not to implement > one of two options above. We can get both: working autoloads and > working built-in help function (+newcommers won't be so frustrated). Of course. The glue code for that would go into guix-emacs.el, just like our autoload glue. > Personally, I'm quite happy that packages got their own > subdirectories and I'm fully satisfied with current state of it, but > it would be cool if inexperienced users will be able to use at least > built-in help commands for packages out of the box without additional > configuration. > > Hope my original point is a little better worded now. Doing something in Emacs without configuration sounds like an oxymoron, but I get your point. At the same time, I think that this kind of change is a pretty large request (DPD has more than 100 lines not counting dependencies, it's not small and neat like guix-emacs.el). If you find a clever trick to make your troubles go away, do submit a patch, but don't let it rely on user setup (in particular, don't rely on "haha, the user always carries about the elpa subdirectory"). Regards, Leo
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
> the "-pkg\\.el$" exclude might have existed for a reason > (I don't know which, put perhaps byte compilation). Perhaps it should be ignored during byte compilation, but still installing it seems to be a good idea. Ok, let's wait for Maxim answer. > I know people take package.el for granted nowadays, but alternative > package managers for Emacs have their uses. This is not just a Guix > thing :) Why not take it for granted?) It's built-in since 24(?), elpa/melpa archives respect it format and provide package descriptions in -pkg.el format, AFAIK. Most other package managers seem to respect "infrastructure" provided by package.el. For example you can view a list of packages with `list-packages` even for packages installed with other PMs (Nix for example), BTW they keep "package.el" directory structure. https://0x0.st/-BxL.txt Don't see too many reasons not to follow this format. I mean it's easily fixable with current directory structure just by stripping "/elpa" suffix from package-directory-list, but why we would do that emacs "customization" instead of just placing packages under /elpa subdirectory and make everything work out of the box? > I don't think we want to fake elpa that hard. Two iterations ago it > was .guix.d and people didn't really like it. Do you mean the package installation path was site-lisp/.guix.d/NAME-VERSION? > My subdirs.el patch is also stretching it. Not sure what you mean by this, sorry, I'm not native speaker and automated translation doesn't make sense to me. Rephrase please. I do not insist on any particular directory structure, just curious why not to stick to the widely adopted format. Once again, thank you for placing packages into subdirectories, now the site-lisp structure seems more organized and less polluted + problem with describe-package (C-h P) and list-packages are easily fixable. Appreciate your work!) -- Best regards, Andrew Tropin
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
Hi, Andrew Tropin skribis: > M-x list-packages ;; Doesn't list treemacs Let me recommend Emacs-Guix (aka. ‘guix.el’) as a superior alternative. :-) I think it’s fine that ‘package.el’ is unaware of Guix-managed software and vice-versa. Ludo’.
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
Am Dienstag, den 11.05.2021, 21:55 +0300 schrieb Andrew Tropin: > > the "-pkg\\.el$" exclude might have existed for a reason > > (I don't know which, put perhaps byte compilation). > > Perhaps it should be ignored during byte compilation, but still > installing it seems to be a good idea. Ok, let's wait for Maxim > answer. I think we agree on that. > > I know people take package.el for granted nowadays, but alternative > > package managers for Emacs have their uses. This is not just a > > Guix thing :) > > Why not take it for granted?) It's built-in since 24(?), elpa/melpa > archives respect it format and provide package descriptions in > -pkg.el format, AFAIK. el-get[1] is still active. straight.el[2] is another package manager for Emacs, its README comparing 5+1 approaches for package mangers, including el-get and package.el. Those are very much wild lands, I say. Not to speak for all the distro-specific ways of handling things. Gentoo had (and probably still has) an overlay, that magically creates Gentoo packages from elpa – in which of course they drop the -pkg.el. Debian has a mix of elpa packages and non-elpa ones, some of which naturally don't have the -pkg.el either. (Also their packages use site-lisp/elpa-src instead of site-lisp/elpa). Arch also seems to install at least some Elisp packages "directly" in site-lisp/$PACKAGE. > Most other package managers seem to respect "infrastructure" provided > by package.el. I don't think that statement is well-supported by the data we have. > Don't see too many reasons not to follow this format. > > I mean it's easily fixable with current directory structure just by > stripping "/elpa" suffix from package-directory-list, but why we > would do that emacs "customization" instead of just placing packages > under /elpa subdirectory and make everything work out of the box? Why should we let ELPA dictate our layout? I have not even once tried customizing package.el for actual use since I got Guix, because the elpa importer is trivial. > > I don't think we want to fake elpa that hard. Two iterations ago > > it was .guix.d and people didn't really like it. > > Do you mean the package installation path was site-lisp/.guix.d/NAME- > VERSION? Yep, that was a kinda ELPA-y convention while also remaining more true to what we're doing. > > My subdirs.el patch is also stretching it. > > Not sure what you mean by this, sorry, I'm not native speaker and > automated translation doesn't make sense to me. Rephrase please. The patch, which I've made, that adds subdirs.el is not uncontroversial. > I do not insist on any particular directory structure, just curious > why not to stick to the widely adopted format. Once again, thank you > for placing packages into subdirectories, now the site-lisp structure > seems more organized and less polluted + problem with describe- > package (C-h P) and list-packages are easily fixable. Appreciate > your work!) I hope I've shed some light as to how "wide" this adoption actually is – Emacs users are a contentious people. Just because something is "the default" and enjoys being shipped with Emacs itself doesn't mean that everyone is happy with it. Thus we're not trying to keep in line with any specific package manager, we just need to make things work "with Emacs" in the sense that packages installed via Guix should have working autoloads and one should be able to (require ...) them. Regards, Leo [1] https://github.com/dimitri/el-get [2] https://github.com/raxod502/straight.el
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
> The problem here is, that Guix does not include the -pkg.el > file, that would typically be generated by package.el. To deal with > this, you have to provide package specs on your own. There already > exists a utility to locate libraries in a package manager agnostic > fashion [1], all you need to do is to feed back that information to > package.el. Yep, I figured it out yesterday and even hacked around a little bit. Patched emacs-build-system to place packages under elpa/NAME-VERSION subdirectory and removed "-pkg\\.el$" from %default-exclude. > I have now published emacs-dpd [2], which does exactly that. To use it > for your Guix Emacs packages, execute > (dpd (list "$GUIX_PROFILE/share/emacs/site-lisp" ...)) > replacing "$GUIX_PROFILE" with the actual profile, after `package- > initialize' has run with `dpd-fuzzy-recognize' in `dpd-recognize-hook'. > I might write a more detailed README later. Most of the packages already have -pkg.el in sources, but yep, pretty cool utility, also thought about implementing something like that yesterday, but luckily I didn't and now I do not need to do it, because now I'm aware of already-existing implementations!) > Neither packed nor dpd are currently packaged in Guix. packed can > easily be imported from melpa-stable, but for dpd you'd have to write > your own guix.scm. I might do that at some point as well. > We already had modifications in emacs-build-system recently, so if you > want to argue, that all Emacs packages should have that - > pkg.el to work with package.el out of the box, I would ask you to wait, > so as to not cause an "Emacs world" rebuild again after only ten days. > I also don't know whether Guix has the same information as package.el > at build time, but that might change with time as well. Particularly, > there will hopefully be a move towards supplying name and version at > build, which would give us the most important information. Very cool, I didn't have the latest changes on my local checkout and didn't see your commits, but now I see, it is exactly what I needed. The only side note: it should be site-lisp/elpa/NAME-VERSION (right now it is site-lisp/NAME-VERSION). Also, on line 137 elpa-directory function can be used. When you will be updating the path, please remove -pkg.el from %default-exclude. Thank you very much for your work! Really appreciate it! -- Best regards, Andrew Tropin
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
Am Dienstag, den 11.05.2021, 18:57 +0300 schrieb Andrew Tropin: > Patched emacs-build-system to place packages under elpa/NAME-VERSION > subdirectory and removed "-pkg\\.el$" from %default-exclude. I don't know whether that's a good idea. The elpa/ part I already dislike, and the "-pkg\\.el$" exclude might have existed for a reason (I don't know which, put perhaps byte compilation). > > I have now published emacs-dpd [2], which does exactly that. To > > use it > > for your Guix Emacs packages, execute > > (dpd (list "$GUIX_PROFILE/share/emacs/site-lisp" ...)) > > replacing "$GUIX_PROFILE" with the actual profile, after `package- > > initialize' has run with `dpd-fuzzy-recognize' in `dpd-recognize- > > hook'. > > I might write a more detailed README later. > > Most of the packages already have -pkg.el in sources, but yep, pretty > cool utility, also thought about implementing something like that > yesterday, but luckily I didn't and now I do not need to do it, > because > now I'm aware of already-existing implementations!) I know people take package.el for granted nowadays, but alternative package managers for Emacs have their uses. This is not just a Guix thing :) > > Neither packed nor dpd are currently packaged in Guix. packed can > > easily be imported from melpa-stable, but for dpd you'd have to > > write > > your own guix.scm. I might do that at some point as well. > > We already had modifications in emacs-build-system recently, so if > > you > > want to argue, that all Emacs packages should have that - > > pkg.el to work with package.el out of the box, I would ask you to > > wait, > > so as to not cause an "Emacs world" rebuild again after only ten > > days. > > I also don't know whether Guix has the same information as > > package.el > > at build time, but that might change with time as > > well. Particularly, > > there will hopefully be a move towards supplying name and version > > at > > build, which would give us the most important information. > > Very cool, I didn't have the latest changes on my local checkout and > didn't > see your commits, but now I see, it is exactly what I needed. > > The only side note: it should be site-lisp/elpa/NAME-VERSION (right > now > it is site-lisp/NAME-VERSION). Also, on line 137 elpa-directory > function can be used. I don't think we want to fake elpa that hard. Two iterations ago it was .guix.d and people didn't really like it. My subdirs.el patch is also stretching it. So I really don't want to add another subdirectory layer to it. If elpa can't deal with that, we'll have to code around it in Elisp. > When you will be updating the path, please remove -pkg.el from > %default-exclude. I've CC'd Maxim, perhaps they know more about %default-exclude. Regards, Leo
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
Am Montag, den 10.05.2021, 10:51 +0300 schrieb Andrew Tropin: > describe-package and list-packages do not show emacs packages, > installed > with guix. Packages themselves work perfectly fine, but not listed in > list-packages and can't be accessed with describe-package. > > Way to reproduce: > > guix environment --pure --ad-hoc emacs emacs-treemacs > > emacs -q > > M-x treemacs ;; Works fine > C-h P treemacs ;; Doesn't work > M-x list-packages ;; Doesn't list treemacs > > Played around with it a little bit, still not sure how to solve. This mail brought me back to the good old days of 2018, when I was still using Gentoo and had to solve a similar issue. The problem here is, that Guix does not include the -pkg.el file, that would typically be generated by package.el. To deal with this, you have to provide package specs on your own. There already exists a utility to locate libraries in a package manager agnostic fashion [1], all you need to do is to feed back that information to package.el. I have now published emacs-dpd [2], which does exactly that. To use it for your Guix Emacs packages, execute (dpd (list "$GUIX_PROFILE/share/emacs/site-lisp" ...)) replacing "$GUIX_PROFILE" with the actual profile, after `package- initialize' has run with `dpd-fuzzy-recognize' in `dpd-recognize-hook'. I might write a more detailed README later. Neither packed nor dpd are currently packaged in Guix. packed can easily be imported from melpa-stable, but for dpd you'd have to write your own guix.scm. I might do that at some point as well. We already had modifications in emacs-build-system recently, so if you want to argue, that all Emacs packages should have that - pkg.el to work with package.el out of the box, I would ask you to wait, so as to not cause an "Emacs world" rebuild again after only ten days. I also don't know whether Guix has the same information as package.el at build time, but that might change with time as well. Particularly, there will hopefully be a move towards supplying name and version at build, which would give us the most important information. Regards, Leo [1] https://github.com/emacscollective/packed [2] https://gitlab.com/leoprikler/emacs-dpd
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
describe-package and list-packages do not show emacs packages, installed with guix. Packages themselves work perfectly fine, but not listed in list-packages and can't be accessed with describe-package. Way to reproduce: guix environment --pure --ad-hoc emacs emacs-treemacs emacs -q M-x treemacs ;; Works fine C-h P treemacs ;; Doesn't work M-x list-packages ;; Doesn't list treemacs Played around with it a little bit, still not sure how to solve.