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

[Leo Prikler]

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.