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

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

[Alex Kost]

I should have asked this when emacs-build-system was introduced.  Why
does it put emacs packages in sub-directories of
"/share/emacs/site-lisp/guix.d"?  It looks more natural to me just to
use "/share/emacs/site-lisp".

I don't see any potential conflicts here: some packages will put their
elisp files right in the site-lisp dir (gnu-build-system does it by
default), and emacs-build-system can just use
"/share/emacs/site-lisp/<package>" sub-directories.

"guix.d" seems redundant to me.  What do people think?

-- 
Alex

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

[Federico Beffa]

On Sun, May 8, 2016 at 12:33 PM, Alex Kost <alezost@gmail.com> wrote:
> I should have asked this when emacs-build-system was introduced.  Why
> does it put emacs packages in sub-directories of
> "/share/emacs/site-lisp/guix.d"?  It looks more natural to me just to
> use "/share/emacs/site-lisp".
>
> I don't see any potential conflicts here: some packages will put their
> elisp files right in the site-lisp dir (gnu-build-system does it by
> default), and emacs-build-system can just use
> "/share/emacs/site-lisp/<package>" sub-directories.
>
> "guix.d" seems redundant to me.  What do people think?

Answer here:

https://lists.gnu.org/archive/html/guix-devel/2015-06/msg00398.html

Regards,
Fede

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

[Alex Kost]

Federico Beffa (2016-05-08 19:23 +0300) wrote:

> On Sun, May 8, 2016 at 12:33 PM, Alex Kost <alezost@gmail.com> wrote:
>> I should have asked this when emacs-build-system was introduced.  Why
>> does it put emacs packages in sub-directories of
>> "/share/emacs/site-lisp/guix.d"?  It looks more natural to me just to
>> use "/share/emacs/site-lisp".
>>
>> I don't see any potential conflicts here: some packages will put their
>> elisp files right in the site-lisp dir (gnu-build-system does it by
>> default), and emacs-build-system can just use
>> "/share/emacs/site-lisp/<package>" sub-directories.
>>
>> "guix.d" seems redundant to me.  What do people think?
>
> Answer here:
>
> https://lists.gnu.org/archive/html/guix-devel/2015-06/msg00398.html

No it is not :-)  I think you miss-understood my point.

You said that we should put emacs packages into subdirectories, and I
agree with this, but instead of the current:

  ".../site-lisp/guix.d/PACKAGE-NAME-VERSION/"

I suggest to use:

  ".../site-lisp/PACKAGE-NAME-VERSION/"

i.e., to remove "guix.d".

-- 
Alex

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

[Federico Beffa]

On Sun, May 8, 2016 at 9:51 PM, Alex Kost <alezost@gmail.com> wrote:
> Federico Beffa (2016-05-08 19:23 +0300) wrote:
>
>> On Sun, May 8, 2016 at 12:33 PM, Alex Kost <alezost@gmail.com> wrote:
>>> I should have asked this when emacs-build-system was introduced.  Why
>>> does it put emacs packages in sub-directories of
>>> "/share/emacs/site-lisp/guix.d"?  It looks more natural to me just to
>>> use "/share/emacs/site-lisp".
>>>
>>> I don't see any potential conflicts here: some packages will put their
>>> elisp files right in the site-lisp dir (gnu-build-system does it by
>>> default), and emacs-build-system can just use
>>> "/share/emacs/site-lisp/<package>" sub-directories.
>>>
>>> "guix.d" seems redundant to me.  What do people think?
>>
>> Answer here:
>>
>> https://lists.gnu.org/archive/html/guix-devel/2015-06/msg00398.html
>
> No it is not :-)  I think you miss-understood my point.
>
> You said that we should put emacs packages into subdirectories, and I
> agree with this, but instead of the current:
>
>   ".../site-lisp/guix.d/PACKAGE-NAME-VERSION/"
>
> I suggest to use:
>
>   ".../site-lisp/PACKAGE-NAME-VERSION/"
>
> i.e., to remove "guix.d".

Yes, I understand your question and the answer is at the link I gave
you (and the remainder of the thread). Here pasted for you again:

"
the reason for using separate sub-directories is that many packages
include files, such as README, ChangeLog, ..., that are likely to
clash. Even if we would delete all non ".el" files (which probably is
not safe), with more than 2500 packages on MELPA, it is possible that
we would still experience some name clashes. I can imagine that
someone preparing a package may be unaware of the existence of some
other package, possibly not very popular in his circle.
"

For further discussions follow the mentioned thread.

Fede

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

[Federico Beffa]

On Sun, May 8, 2016 at 10:06 PM, Federico Beffa <beffa@ieee.org> wrote:
> On Sun, May 8, 2016 at 9:51 PM, Alex Kost <alezost@gmail.com> wrote:
>> Federico Beffa (2016-05-08 19:23 +0300) wrote:
>>
>>> On Sun, May 8, 2016 at 12:33 PM, Alex Kost <alezost@gmail.com> wrote:
>>>> I should have asked this when emacs-build-system was introduced.  Why
>>>> does it put emacs packages in sub-directories of
>>>> "/share/emacs/site-lisp/guix.d"?  It looks more natural to me just to
>>>> use "/share/emacs/site-lisp".
>>>>
>>>> I don't see any potential conflicts here: some packages will put their
>>>> elisp files right in the site-lisp dir (gnu-build-system does it by
>>>> default), and emacs-build-system can just use
>>>> "/share/emacs/site-lisp/<package>" sub-directories.
>>>>
>>>> "guix.d" seems redundant to me.  What do people think?
>>>
>>> Answer here:
>>>
>>> https://lists.gnu.org/archive/html/guix-devel/2015-06/msg00398.html
>>
>> No it is not :-)  I think you miss-understood my point.
>>
>> You said that we should put emacs packages into subdirectories, and I
>> agree with this, but instead of the current:
>>
>>   ".../site-lisp/guix.d/PACKAGE-NAME-VERSION/"
>>
>> I suggest to use:
>>
>>   ".../site-lisp/PACKAGE-NAME-VERSION/"
>>
>> i.e., to remove "guix.d".

OK, indeed I did misunderstood.

"guix.d" was added for the following reasons.

* There are some packages generating sub-directories. If one of those
packages is not installed with the 'emacs-build-system', say because
it provides configure/make scripts, then it may not be obvious which
directory to add to the path in an automatic way. With "guix.d" you
just add one layer down into each sub-directory.

* It also makes it obvious that packages into that directory are
installed in a guix specific way. Therefore, if you try to use them
with an emacs from a foreign distro, you know that you have to do
something to make them work.

I'm therefore in favor of keeping "guix.d".

Fede

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

[Alex Kost]

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

> On Sun, May 8, 2016 at 9:51 PM, Alex Kost <alezost@gmail.com> wrote:
>
>> You said that we should put emacs packages into subdirectories, and I
>> agree with this, but instead of the current:
>>
>>   ".../site-lisp/guix.d/PACKAGE-NAME-VERSION/"
>>
>> I suggest to use:
>>
>>   ".../site-lisp/PACKAGE-NAME-VERSION/"
>>
>> i.e., to remove "guix.d".
>
> OK, indeed I did misunderstood.
>
> "guix.d" was added for the following reasons.
>
> * There are some packages generating sub-directories. If one of those
> packages is not installed with the 'emacs-build-system', say because
> it provides configure/make scripts, then it may not be obvious which
> directory to add to the path in an automatic way. With "guix.d" you
> just add one layer down into each sub-directory.

Sorry, I don't understand what you mean.  Sub-directories like
"site-lisp/guix.d/<package>/foo/"?  Why can't it be just
"site-lisp/<package>/foo/".  Could you give an example?

> * It also makes it obvious that packages into that directory are
> installed in a guix specific way. Therefore, if you try to use them
> with an emacs from a foreign distro, you know that you have to do
> something to make them work.

You don't have to do anything to make them work if you use emacs from
Guix.  Also I don't think that making it obvious that this is a guix
specific directory is needed.  Moreover it may be confusing (see [1]).
I would wonder why there is this an additional layer in elisp hierarchy,
and I actually wonder… I mean I don't like it.

> I'm therefore in favor of keeping "guix.d".

OK, I see.  So it's 1 for keeping "guix.d" part and 1 for removing it.
Please people give your opinions!

[1] https://gnunet.org/bot/log/guix/2016-05-07#T1022796

P.S.  I'm very sorry for this stupid and not funny joke, but let's
"improve" the current situation by adding more levels to the file
hierarchy:

  .../share/emacs/site-lisp/this/is/a-guix-specific/directory/<package>

-- 
Alex-the-hooligan

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

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> Federico Beffa (2016-05-09 09:42 +0300) wrote:
>
>> On Sun, May 8, 2016 at 9:51 PM, Alex Kost <alezost@gmail.com> wrote:

[...]

>> * It also makes it obvious that packages into that directory are
>> installed in a guix specific way. Therefore, if you try to use them
>> with an emacs from a foreign distro, you know that you have to do
>> something to make them work.
>
> You don't have to do anything to make them work if you use emacs from
> Guix.  Also I don't think that making it obvious that this is a guix
> specific directory is needed.  Moreover it may be confusing (see [1]).
> I would wonder why there is this an additional layer in elisp hierarchy,
> and I actually wonder… I mean I don't like it.
>
>> I'm therefore in favor of keeping "guix.d".
>
> OK, I see.  So it's 1 for keeping "guix.d" part and 1 for removing it.
> Please people give your opinions!

Let’s make sure we understand each other before we vote.  :-)

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 think that’s a reasonable concern, and probably a sufficient reason
for the status quo.

WDYT?

Ludo’.

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

[Alex Kost]

Ludovic Courtès (2016-05-17 00:15 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Federico Beffa (2016-05-09 09:42 +0300) wrote:
>>
>>> On Sun, May 8, 2016 at 9:51 PM, Alex Kost <alezost@gmail.com> wrote:
>
> [...]
>
>>> * It also makes it obvious that packages into that directory are
>>> installed in a guix specific way. Therefore, if you try to use them
>>> with an emacs from a foreign distro, you know that you have to do
>>> something to make them work.
>>
>> You don't have to do anything to make them work if you use emacs from
>> Guix.  Also I don't think that making it obvious that this is a guix
>> specific directory is needed.  Moreover it may be confusing (see [1]).
>> I would wonder why there is this an additional layer in elisp hierarchy,
>> and I actually wonder… I mean I don't like it.
>>
>>> I'm therefore in favor of keeping "guix.d".
>>
>> OK, I see.  So it's 1 for keeping "guix.d" part and 1 for removing it.
>> Please people give your opinions!
>
> Let’s make sure we understand each other before we vote.  :-)

I think I understand your (I mean Federico and you) point.

> 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 think that’s a reasonable concern, and probably a sufficient reason
> for the status quo.
>
> WDYT?

As I said I see "guix.d" as an extra (and unnecessary) layer in the file
hierarchy, so I don't like it.

-- 
Alex

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

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> Ludovic Courtès (2016-05-17 00:15 +0300) wrote:
>
>> Alex Kost <alezost@gmail.com> skribis:
>>
>>> Federico Beffa (2016-05-09 09:42 +0300) wrote:
>>>
>>>> On Sun, May 8, 2016 at 9:51 PM, Alex Kost <alezost@gmail.com> wrote:
>>
>> [...]
>>
>>>> * It also makes it obvious that packages into that directory are
>>>> installed in a guix specific way. Therefore, if you try to use them
>>>> with an emacs from a foreign distro, you know that you have to do
>>>> something to make them work.
>>>
>>> You don't have to do anything to make them work if you use emacs from
>>> Guix.  Also I don't think that making it obvious that this is a guix
>>> specific directory is needed.  Moreover it may be confusing (see [1]).
>>> I would wonder why there is this an additional layer in elisp hierarchy,
>>> and I actually wonder… I mean I don't like it.
>>>
>>>> I'm therefore in favor of keeping "guix.d".
>>>
>>> OK, I see.  So it's 1 for keeping "guix.d" part and 1 for removing it.
>>> Please people give your opinions!
>>
>> Let’s make sure we understand each other before we vote.  :-)
>
> I think I understand your (I mean Federico and you) point.
>
>> 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?

Thanks,
Ludo’.

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

[Federico Beffa]

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

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

[Alex Kost]

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

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

[Federico Beffa]

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.

>
>> 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 you made
examples of them and said that you would prefer not to "fix" them.

I think you are missing the whole idea of the emacs-build-system. It
is intended to replicate the behavior of Emacs's packaging system,
that is to be used with emacs package tar files only. Emacs packages
are installed in ~.emacs.d/elpa and they are packaged do include
non-elisp files because Emacs run as a user has no permission to put
them in system locations. The  emacs-build-system simply replaces
~/.emacs.d/elpa with ~/.guix-profile/share/emacs/site-lisp/guix.d.
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.

Regards,
Fede

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

[Alex Kost]

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

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

[Ludovic Courtès]

Hello Guix!

Alex Kost <alezost@gmail.com> skribis:

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

I’ve read the messages that the two of you sent with interest.  I just
wanted to add that, no matter what, it’s not a subject worth losing our
hair on.  :-)

Ludo’.

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

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> I should have asked this when emacs-build-system was introduced.  Why
> does it put emacs packages in sub-directories of
> "/share/emacs/site-lisp/guix.d"?  It looks more natural to me just to
> use "/share/emacs/site-lisp".
>
> I don't see any potential conflicts here: some packages will put their
> elisp files right in the site-lisp dir (gnu-build-system does it by
> default), and emacs-build-system can just use
> "/share/emacs/site-lisp/<package>" sub-directories.
>
> "guix.d" seems redundant to me.  What do people think?

I think there was a Good Reason™.  Isn’t it that we wanted to mimic what
package.el does, while avoiding collisions with package.el-installed
software?

Ludo’.

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

[Alex Kost]

Ludovic Courtès (2016-05-08 19:51 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> I should have asked this when emacs-build-system was introduced.  Why
>> does it put emacs packages in sub-directories of
>> "/share/emacs/site-lisp/guix.d"?  It looks more natural to me just to
>> use "/share/emacs/site-lisp".
>>
>> I don't see any potential conflicts here: some packages will put their
>> elisp files right in the site-lisp dir (gnu-build-system does it by
>> default), and emacs-build-system can just use
>> "/share/emacs/site-lisp/<package>" sub-directories.
>>
>> "guix.d" seems redundant to me.  What do people think?
>
> I think there was a Good Reason™.  Isn’t it that we wanted to mimic what
> package.el does, while avoiding collisions with package.el-installed
> software?

Yes, the Good Reason was to avoid potential collisions of thousands of
emacs packages.  I probably wasn't clear enough, I just wanted to say
that "guix.d" part of a package file name can be removed.  I suggest
this:

  .../share/emacs/site-lisp/<package>

instead of this (currently used):

  .../share/emacs/site-lisp/guix.d/<package>

I can work on a patch for this change, if it sounds reasonable.

-- 
Alex