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

[Alex Kost <alezost@gmail.com>]

Federico Beffa (2016-05-21 13:47 +0300) wrote:

> On Fri, May 20, 2016 at 11:00 PM, Alex Kost <alezost@gmail.com> wrote:
>> Federico Beffa (2016-05-20 09:53 +0300) wrote:
>>
>
> [...]
>
>>> (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.
>
> a package which includes sub-directories not including .el files.

So you mean this:

  .../share/emacs/site-lisp/<package>/<subdir-with-non-elisp>

There is absolutely no problem with this.  Originally you said that
non-elisp dirs may be wrongfully added to 'load-path', but this will
never happen because only <package> dir will be added.

>>> 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?
>
> you can't distinguish it from a package installed with, say,
> gnu-build-system including non elisp sub-directories.

And such distinguishing is not needed!  You will have *.el files in
"share/emacs/site-lisp/<package>/" and it doesn't matter what build
system puts these files there.  Non-elisp sub-directories doesn't make
any difference.

> And you made
> examples of them and said that you would prefer not to "fix" them.

Exactly, because it is not needed.  For example, magit places its files
to "share/emacs/site-lisp/magit" dir by default, so if "site-lisp"
subdirs will be handled as we handle "site-lisp/guix.d" subdirs now,
there will be no need to change this default behaviour of magit.

> I think you are missing the whole idea of the emacs-build-system.

With all respect, no I don't miss this idea.

> It
> is intended to replicate the behavior of Emacs's packaging system,

This is unrelated, but it does not replicate it fully, because we don't
create *-pkg.el files, so the in-built emacs package system ("M-x
list-packages") can't see these packages, even if ".../guix.d" dir will
be added to 'package-directory-list' variable.  Mathieu mentioned this
feature used by debian on IRC¹

> that is to be used with emacs package tar files only. Emacs packages
> are installed in ~.emacs.d/elpa and they are packaged to include
> non-elisp files because Emacs run as a user has no permission to put

I can only repeat that there is no problem with non-elisp files.

> them in system locations. The  emacs-build-system simply replaces
> ~/.emacs.d/elpa with ~/.guix-profile/share/emacs/site-lisp/guix.d.

Yes, and all I suggest is to replace ~/.emacs.d/elpa with
~/.guix-profile/share/emacs/site-lisp.  Why to use additional "guix.d"
subdir?

> That's all. For the rest the two systems are intended to behave the
> same. If you change the location of files it's likely that the
> packages will not work and you open a can of worms with infinite
> fixes.

It is absolutely unlikely that the packages will not work.  They will
work as they work now!  It doesn't matter what directory we use to place
the packages in.  It can be:

  ~/.guix-profile/share/emacs/site-lisp/guix.d/guix.d/guix.d/  or
  ~/.guix-profile/share/emacs/site-lisp/guix.d/  or
  ~/.guix-profile/whatever/we/want/  or
  ~/.guix-profile/share/emacs/site-lisp/

The last one looks the most appropriate for me.

I'm sure that I'm right, and I see you're sure you're right.  I tried
hardly to explain my point, and I'm sure you still don't understand what
I want to say.  I think you are sure that I don't understand the
potential problems you see.

But I agree with you that this will not be a technical improvement
anyway, so I better spend my time on other things, let's leave "guix.d"
alone for now.  But I will tell my point on "guix.d" every time and
everywhere it will be mentioned :-)

¹ https://gnunet.org/bot/log/guix/2016-05-12#T1027988

-- 
Alex