[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why do we use ".../share/emacs/site-lisp/guix.d/"?
From: |
Alex Kost |
Subject: |
Re: Why do we use ".../share/emacs/site-lisp/guix.d/"? |
Date: |
Sat, 21 May 2016 00:00:20 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Federico Beffa (2016-05-20 09:53 +0300) wrote:
> address@hidden (Ludovic Courtès) writes:
>
>> Alex Kost <address@hidden> skribis:
>>
>>> Ludovic Courtès (2016-05-17 00:15 +0300) wrote:
>>>
>>>> Alex Kost <address@hidden> 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
- Why do we use ".../share/emacs/site-lisp/guix.d/"?, Alex Kost, 2016/05/08
- Re: Why do we use ".../share/emacs/site-lisp/guix.d/"?, Federico Beffa, 2016/05/08
- Re: Why do we use ".../share/emacs/site-lisp/guix.d/"?, Alex Kost, 2016/05/08
- Re: Why do we use ".../share/emacs/site-lisp/guix.d/"?, Federico Beffa, 2016/05/08
- Re: Why do we use ".../share/emacs/site-lisp/guix.d/"?, Federico Beffa, 2016/05/09
- Re: Why do we use ".../share/emacs/site-lisp/guix.d/"?, Alex Kost, 2016/05/09
- Re: Why do we use ".../share/emacs/site-lisp/guix.d/"?, Ludovic Courtès, 2016/05/16
- Re: Why do we use ".../share/emacs/site-lisp/guix.d/"?, Alex Kost, 2016/05/17
- Re: Why do we use ".../share/emacs/site-lisp/guix.d/"?, Ludovic Courtès, 2016/05/19
- Re: Why do we use ".../share/emacs/site-lisp/guix.d/"?, Federico Beffa, 2016/05/20
- Re: Why do we use ".../share/emacs/site-lisp/guix.d/"?,
Alex Kost <=
- Re: Why do we use ".../share/emacs/site-lisp/guix.d/"?, Federico Beffa, 2016/05/21
- Re: Why do we use ".../share/emacs/site-lisp/guix.d/"?, Alex Kost, 2016/05/21
- Re: Why do we use ".../share/emacs/site-lisp/guix.d/"?, Ludovic Courtès, 2016/05/22
Re: Why do we use ".../share/emacs/site-lisp/guix.d/"?, Ludovic Courtès, 2016/05/08