From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: feature/integrated-elpa 4f6df43 15/23: README added Date: Sat, 15 Oct 2016 18:21:30 +0300 Message-ID: <83inst1vut.fsf@gnu.org> References: <20160916203414.25203.87032@vcs.savannah.gnu.org> <8337k7hysd.fsf@gnu.org> <8660p3qd99.fsf@realize.ch> <831szrhwsr.fsf@gnu.org> <8760p12qzw.fsf@russet.org.uk> <83vax0en1u.fsf@gnu.org> <87pon5ek3q.fsf@russet.org.uk> <87twcgttjf.fsf@russet.org.uk> <86a8e7symk.fsf@realize.ch> <8737jzl4u9.fsf@russet.org.uk> <8337jz8dg8.fsf@gnu.org> <83insv3tnl.fsf@gnu.org> <83d1j33qgg.fsf@gnu.org> <87wph96cto.fsf@russet.org.uk> <831szh3iq4.fsf@gnu.org> <87mvi5spl9.fsf@Rainer.invalid> <83mvi51y3b.fsf@gnu.org> <87instslxu.fsf@russet.org.uk> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1476544936 30306 195.159.176.226 (15 Oct 2016 15:22:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 15 Oct 2016 15:22:16 +0000 (UTC) Cc: Stromeko@nexgo.de, emacs-devel@gnu.org To: phillip.lord@russet.org.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 15 17:22:12 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bvQmS-0004dI-4U for ged-emacs-devel@m.gmane.org; Sat, 15 Oct 2016 17:21:48 +0200 Original-Received: from localhost ([::1]:52318 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bvQmQ-0008U4-Od for ged-emacs-devel@m.gmane.org; Sat, 15 Oct 2016 11:21:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60303) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bvQmJ-0008T1-TB for emacs-devel@gnu.org; Sat, 15 Oct 2016 11:21:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bvQmF-0008J6-Lx for emacs-devel@gnu.org; Sat, 15 Oct 2016 11:21:38 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47031) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bvQmF-0008IT-IA; Sat, 15 Oct 2016 11:21:35 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4703 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bvQmD-0004UZ-J3; Sat, 15 Oct 2016 11:21:34 -0400 In-reply-to: <87instslxu.fsf@russet.org.uk> (phillip.lord@russet.org.uk) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:208295 Archived-At: > From: phillip.lord@russet.org.uk (Phillip Lord) > Cc: Achim Gratz , emacs-devel@gnu.org > Date: Sat, 15 Oct 2016 15:53:33 +0100 > > Eli Zaretskii writes: > > >> From: Achim Gratz > >> Date: Sat, 15 Oct 2016 15:34:42 +0200 > >> > >> >> Except that it doesn't. Try this. Take Emacs 24.3, M-x package-install > >> >> org. Now do, M-x load-library org-html. As you might expect org-html is > >> >> duly loaded. > >> > > >> > How is this relevant to the issue at hand, though? If you want to > >> > solve this problem, all you need to is place all the ELPA directories > >> > in load-path ahead of the standard ones, that's all. > >> > >> How do you suppose the autoload for the no longer existing org-html will > >> be excised from the autoloads file in the old Emacs? > > > > Once again, how is this relevant to the directory structure of Lisp > > files? Can a particular structure solve this problem, where other > > structures don't? > > Yes. Package.el solves this problem quite nicely. We have: > > ~/.emacs.d/elpa/org-mode-1.6/org-html.el > ~/.emacs.d/elpa/org-mode-1.8/ox-html.el > > package.el solves the problem that org-html.el no longer exists simply > by not adding org-mode-1.6 to the load path. Nor does it load > "org-autoloads.el". So, even though org-html.el is still around on the > hard drive, it is ignored by emacs. The same can be done with any other directory structure, in two steps: (1) put the new directory first in load-path, and (2) don't load org-autoloads.el. Right? > Now, as it happens, with the current directory organisation of Emacs, we > can solve the problem anyway, by doing the same trick in core. But, > currently, we don't. That's exactly what I meant: we can do this with any directory structure. IOW the directory structure is not relevant to this issue. > And this could only work for org.el *because* org is in it's own > directory with its own autoloads file. For seq.el, for instance, it will > not work. So one solution would be to provide a separate autoloads file for each package that lives on ELPA. That again has nothing to do with the directory structure. Right? (There could also be other solutions.) > IIUC, in fact it's the org-mode folks actually view this as a > significant *disadvantage* to having org-mode in core. What is "this" that the Org folks see as a disadvantage? > There are a few other things that package.el does, which it would be > shame to loose. It checks dependencies for instance. So, say, I > installed assess.el into Emacs core using package.el as I suggest, and > it requires a newer version of seq.el than is available, package.el will > bitch about this very early. I don't see why we'd have to lose this. No one said we are throwing away package.el. We are talking about _extending_ it. > Bottom line: package.el is a better way of handling packages than core > which is a legacy. Moving wholesale to it is probably not worth the > effort (at least not in the short term). But supporting it in core > definately is. We need to adapt package.el to the new needs. It was not written with these goals in mind, so it needs to learn new tricks. Throwing it away is not acceptable, but neither is blindly accepting its current assumptions, which were not designed for the use case we are discussing.