bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Maxim Cournoyer
Subject: bug#48331: Emacs' describe-package doesn't work for packages managed by guix
Date: Fri, 21 May 2021 23:09:08 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Hello,

Leo Prikler <leo.prikler@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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]