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

[Alex Kost <alezost@gmail.com>]

Federico Beffa (2016-05-20 09:53 +0300) wrote:

> 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.

It wasn't ignored: I asked you to explain what you meant:
<http://lists.gnu.org/archive/html/guix-devel/2016-05/msg00296.html>

> 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/

I think you miss-understood, currently it is:

  site-lisp/guix.d/<package>/*.el
  site-lisp/guix.d/<package>/<subdir-with-non-elisp>

Without "guix.d", it will be:

  site-lisp/<package>/*.el
  site-lisp/<package>/<subdir-with-non-elisp>

So this <subdir-with-non-elisp> will not be added to 'load-path', it is
the <package> directory that will be.

> 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?

Simply every sub-directory should be included in a load-path without
checking what is placed there, because "share/emacs/site-lisp" is for
elisp files, so only evil packages can put directories without elisp
files there (and I don't think such evil packages exist).

> 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.

Yes, and without "guix.d", we would only include site-lisp and its
subdirs.

BTW there are packages that put their elisp files in a site-lisp
sub-directory (e.g., magit, git-modes, mu) and we "fix" them not to do
it.  I think instead of "fixing" them, we should remove "guix.d" layer,
and search for packages in site-lisp subdirs.

> 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.

There is absolutely no harm if an additional directory (even
non-existing) will appear in 'load-path', but as I said I don't think
this will ever happen.  If a package puts only non-elisp files in
"share/emacs/site-lisp/<subdir>", it is a wrong behaviour and we should
fix it.

> 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.

I agree that it is not a technical improvement, but I see this as an
important stylistic improvement.  As for me, "guix.d" is a useless
additional layer and it may be confusing for new-comers.  But you
already know my point :-)

And yes, this will be a breaking change indeed, but a developing
software breaks things from time to time.

> (note 1): If you want an example look at emacs-slime.

Sorry, I really don't understand what you want to illustrate with this
example.

> 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

What extra sub-directory do you mean?  Currently the package is
installed in:

  .../share/emacs/site-lisp/guix.d/slime-2.15/

If we remove "guix.d", it will be:

  .../share/emacs/site-lisp/slime-2.15/

So what's the problem?

BTW I think that ideally *.lisp files should be put somewhere else (I
don't know where), as "share/emacs/site-lisp" is for elisp, not for
common lisp.  But I think it's a problem of the upstream that they
didn't make a proper GNU Build System infrastructure for this complex
emacs package.  I see why you used emacs-build-system here: apparently,
this hand-made Makefile is not intended to be used as a part of the gnu
build system as it doesn't even have "install" target.

> 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).

I don't understand: if a Makefile installs files in wrong places, it is
a bad file, and we should do something about it.  For this particular
case (I mean "emacs-slime"), there is no other option except
emacs-build-system as Makefile is inappropriate.

-- 
Alex