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

Previous Next

Full log

Message #62 received at 48331 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>
Cc: Arun Isaac <arunisaac <at> systemreboot.net>, 48331 <at> debbugs.gnu.org,
 Andrew Tropin <andrew <at> trop.in>
Subject: Re: Emacs' describe-package doesn't work for packages managed by guix
Date: Fri, 21 May 2021 23:09:08 -0400

Hello,

Leo Prikler <leo.prikler <at> student.tugraz.at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.