Re: elisp packages discovery (was: bug#27686: emacs-ess: Not installed in "${output}/share/emacs/site-lisp/guix.d)"

[Maxim Cournoyer]

Hi Alex!

Alex Kost <address@hidden> writes:

> Maxim Cournoyer (2017-08-15 12:08 -0400) wrote:
>
>> On Tue, Jul 18, 2017 at 9:52 AM, Alex Kost <address@hidden> wrote:
> [...]
>>     A side note: this is one of the reasons why I don't like "guix.d"
>>     sub-directory.  I think it is a useless extra level in the file
>>     hierarchy.  If we used:
>>
>>       .../share/emacs/site-lisp/<package>
>>
>> While I agree that packaging elisp files in their own folder is
>> cleaner, it also introduces some complexity such as the requirement
>> to add some glue code in the Emacs site-start.el for packages
>> discovery.
>>
>> This mechanism is only valid when working with a profile;
>> at build time (say, you want to run tests which depend on other Emacs
>> packages), another hack is required + manual fiddling.
>>
>> By contrast, if all of our Emacs packages were laid out flat under
>> the usual share/emacs/site-lisp/ like it's done on other
>> distributions,
>
> I wonder how many emacs packages these distributions provide and whether
> they have any name conflicts in "site-lisp" or not.

I should have researched what I said beforehand; I just looked at how
Debian does it, and it seems they are also isolating package files in
their own subdir under an elpa-src diretory[0], or at least going into
that direction. Their approach is a bit different; they make use of
package.el which ships with Emacs, so they do not need any custom code
in site-start.

Gentoo is also using a <package> subdirectory[1]:
/usr/share/emacs/site-lisp/package/ and rely on some custom site-start
elisp glue for packages discovery. So, I'm not sure if there are any
distribution actually packaging their elisp libraries directly under the
share/emacs/site-lisp like I thought was the case. Sorry for the
misinformation!

>> we could simply define the EMACSLOADPATH `search-path'
>> at the Emacs package definition level, and the rest would be taken
>> care of by Guix native mechanisms (no hacks required).
>>
>> IMHO, this would be more "Guixy".
>
> The only problem with this flat structure I see is the potential name
> conflicts.  Federico (the author of the 'emacs-build-system') explained
> it here:
>
>   http://lists.gnu.org/archive/html/guix-devel/2015-06/msg00398.html

That's a valid concern. Thanks for sharing your thoughts. I'll continue
to ponder about it.

Maxim

[0] https://anonscm.debian.org/cgit/pkg-emacsen/pkg/dh-elpa.git/tree/README.org
[1] https://wiki.gentoo.org/wiki/Project:GNU_Emacs/Developer_guide