From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Kost Subject: Re: Why do we use ".../share/emacs/site-lisp/guix.d/"? Date: Sat, 21 May 2016 00:00:20 +0300 Message-ID: <87h9ds1m3f.fsf@gmail.com> References: <878tzkhmah.fsf@gmail.com> <871t5cwcpd.fsf@gmail.com> <87lh3joapu.fsf@gmail.com> <87vb2du2kz.fsf@gnu.org> <87k2isa6x9.fsf@gmail.com> <874m9uxnlw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44721) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b3t81-0001vx-Vu for guix-devel@gnu.org; Fri, 20 May 2016 18:42:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b3rWy-0000il-OC for guix-devel@gnu.org; Fri, 20 May 2016 17:00:28 -0400 List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Federico Beffa Cc: Guix-devel Federico Beffa (2016-05-20 09:53 +0300) wrote: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> Alex Kost skribis: >> >>> Ludovic Court=C3=A8s (2016-05-17 00:15 +0300) wrote: >>> >>>> Alex Kost skribis: > > [...] > >>>> Federico suggests above that having =E2=80=9Cguix.d=E2=80=9D 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=E2=80=99re 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: > 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//*.el site-lisp/guix.d// Without "guix.d", it will be: site-lisp//*.el site-lisp// So this will not be added to 'load-path', it is the 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/", 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. --=20 Alex