bug#48331: Emacs' describe-package doesn't work for packages managed by guix

[Leo Prikler]

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