Re: Why do we use ".../share/emacs/site-lisp/guix.d/"?

[Federico Beffa <beffa@ieee.org>]

ludo@gnu.org (Ludovic Courtès) writes:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Ludovic Courtès (2016-05-17 00:15 +0300) wrote:
>>
>>> Alex Kost <alezost@gmail.com> skribis:

[...]

>>> Federico suggests above that having “guix.d” makes it clear that a
>>> non-Guix-installed Emacs on a foreign distro may not be able to use
>>> those packages.
>>
>> I don't see how this makes it more clear.  Of course a
>> non-Guix-installed Emacs knows nothing about packages installed in a
>> Guix profile.  As for me, "~/.guix-profile" is already clear enough, and
>> there is no reason to add another "guix"-containing name part to the
>> file hierarchy.
>
> I see, I get your point, and I think I concur.
>
> Federico: is there anything we’re missing from your argument?

Given that the first point that I made appears to have been ignored, I
would think so.

Let me try to explain it once more:

There are packages which do have sub-directories containing only non
elisp files (note 1) and which therefore should not be included in
Emacs's load-path.  If you remove guix.d as you are suggesting, you can
end up with a directory layout as follows:

package-NOT-installed-with-emacs-build-system-a.el
package-NOT-installed-with-emacs-build-system-a/
package-NOT-installed-with-emacs-build-system-b.el
package-installed-with-emacs-build-system-c/
package-installed-with-emacs-build-system-d/

How can you tell which sub-directory to include in Emacs's load-path
without having to scan all of them or relying on heuristics?

Differently from this with the guix.d directory it is very clear:

package-NOT-installed-with-emacs-build-system-a.el
package-NOT-installed-with-emacs-build-system-a/
package-NOT-installed-with-emacs-build-system-b
guix.d/package-installed-with-emacs-build-system-c/
guix.d/package-installed-with-emacs-build-system-d/

you only include '.' (site-lisp) and one level below guix.d.

So, removing guix.d could result in additional directories being
included in Emacs's load-path, or could require a more sophisticated
heuristic strategy to decide which sub-directory to include.  These are
not catastrophic things, but in my opinion plain bad.

The proposed change is a change for the sake of changing things: it does
not provide any tangible technical improvement.  On the contrary, beside
the above, it will break existing installations where people have the
current Emacs package installed and will install a new package without
updating Emacs itself.

Fede

(note 1): If you want an example look at emacs-slime.  Because I
prepared that package, I decided to use the emacs-build-system and so
the extra sub-directory doesn't reside directly under site-lisp.  But it
is likely that there are other similar packages and somebody else may
prefer to install it with a build system other than the
emacs-build-system (using a provided Makefile).