bug#27686: emacs-ess: Not installed in "${output}/share/emacs/site-lisp/guix.d"

[Alex Kost <alezost@gmail.com>]

Maxim Cournoyer (2017-08-15 12:08 -0400) wrote:

> On Tue, Jul 18, 2017 at 9:52 AM, Alex Kost <alezost@gmail.com> 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.

> 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

Although emacs-build-system removes such files as README or .gitignore
nowadays, name conflicts are still possible, especially for "complex"
emacs packages that provide additional non-elisp files, often placed in
sub-directories.  For example, 'emacs-slime' provides 'lib' and
'contrib' subdirs.  There may be other packages that have dirs with the
same names, and since there are thousands of Emacs packages out there,
name conflicts are possible in this case.

Otherwise, I agree that flat structure is much easier to use and handle.

> Alternatively, we would need to extend the seacrh-path facility to be
> able to deal with our own added complexity. I'm not sure if it's
> worth it.

-- 
Alex