From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: feature/integrated-elpa 4f6df43 15/23: README added Date: Sat, 15 Oct 2016 15:53:33 +0100 Message-ID: <87instslxu.fsf@russet.org.uk> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1476543296 30405 195.159.176.226 (15 Oct 2016 14:54:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 15 Oct 2016 14:54:56 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: Achim Gratz , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 15 16:54:50 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 1bvQMC-0005oA-Ea for ged-emacs-devel@m.gmane.org; Sat, 15 Oct 2016 16:54:40 +0200 Original-Received: from localhost ([::1]:52234 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bvQMB-0004MS-99 for ged-emacs-devel@m.gmane.org; Sat, 15 Oct 2016 10:54:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55930) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bvQLJ-0004ML-UI for emacs-devel@gnu.org; Sat, 15 Oct 2016 10:53:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bvQLI-0004Aw-Q1 for emacs-devel@gnu.org; Sat, 15 Oct 2016 10:53:45 -0400 Original-Received: from cloud103.planethippo.com ([31.216.48.48]:36874) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bvQLD-000487-Pm; Sat, 15 Oct 2016 10:53:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From; bh=ABKEvm3XW0KsFdYMA9wQfPm1vDuxw0h680PlsrCACcs=; b=pqoJcA5s7pp0Ybqp4GwCQZmRu3 +1w6+2ddzjj5pnZ1Ge/kS5f3BASKPS2+ogw1j3RnAg5wVz3bgYw56DmgZZ3upz2Pha0Ji3roT6S9w EDq2SavwCNfUxv39vu7goVYuFnVO+ysuhENMwljpdjCob0h5WvZDb9kHrQ6G53Lho4fcfK6awZ43E E73LsxtWztqaZm6YG9aPp5Zntno2vbezSf0C+x9Losg36G95jbb7wirFskUDez49YGXs1SxHjr3YQ zDpRjR2iiPWORtV2tu2yQfLMBo3YE3KtAUk0ts5FyK2Pjhg08VP/1aCDNNpnrZlQ7B15V5AI1X479 lyZ9GcDw==; Original-Received: from cpc14-benw10-2-0-cust305.16-2.cable.virginm.net ([92.234.125.50]:47488 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1bvQLB-000fja-FU; Sat, 15 Oct 2016 15:53:38 +0100 In-Reply-To: <83mvi51y3b.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 15 Oct 2016 17:33:12 +0300") X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud103.planethippo.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - russet.org.uk X-Get-Message-Sender-Via: cloud103.planethippo.com: authenticated_id: phillip.lord@russet.org.uk X-Authenticated-Sender: cloud103.planethippo.com: phillip.lord@russet.org.uk X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 31.216.48.48 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:208292 Archived-At: 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. 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. 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. IIUC, in fact it's the org-mode folks actually view this as a significant *disadvantage* to having org-mode in core. It's only because this is the only way to get it into the tarball that they do it. Achim, do I have this right? 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. We could achieve all of this without package.el, with copying and checking. But why? package.el already does all of this. 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. Phil