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: Wed, 19 Oct 2016 08:51:39 +0100 Message-ID: <8760oosrn8.fsf@russet.org.uk> References: <20160916203414.25203.87032@vcs.savannah.gnu.org> <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> <83inst1vut.fsf@gnu.org> <87eg3ekjz2.fsf@russet.org.uk> <83vawpx677.fsf@gnu.org> <87h989ixxd.fsf@russet.org.uk> <83mvi1ww6m.fsf@gnu.org> <87wph5fw0w.fsf@russet.org.uk> <838ttlwodt.fsf@gnu.org> <878ttl3342.fsf@Rainer.invalid> <8360opwjs2.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1476863539 28006 195.159.176.226 (19 Oct 2016 07:52:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2016 07:52:19 +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 Wed Oct 19 09:52:15 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 1bwlfQ-0005Sf-VF for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 09:52:05 +0200 Original-Received: from localhost ([::1]:46103 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwlfT-0004eE-2E for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 03:52:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60390) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwlfG-0004dH-GU for emacs-devel@gnu.org; Wed, 19 Oct 2016 03:52:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwlf9-0007Aw-TX for emacs-devel@gnu.org; Wed, 19 Oct 2016 03:51:49 -0400 Original-Received: from cloud103.planethippo.com ([31.216.48.48]:51777) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bwlf3-00078R-UB; Wed, 19 Oct 2016 03:51:42 -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=KKaj6sISAvFCFtpKUzPqeqiOQyb3zB1O5heeqINtKEI=; b=lg0ibZ/qv6lx2yto0mvgvBz7OA 9FsmQ4v5UQpH+P/kTlXE32qdyotjLrjoHo5189Tb8f8Yh2v+kTRBNRFbsNwzOS6z4FKp1e0ITrgTC pRUK9+OXWwtSzB7FjAovsNau7mBN6rf9BOSp/EnjV9tqdq6oL4KJKf0mkNWbUKEa3jb9uaY+rDtwJ eYuuAqBIfzNv8qiPLjwR6f0NNaqPcz3qK3tPpG2eLVMlkshU8lKAG9mCO31RKacyZKu5xmLoQ7GHp nIrfdZIT/sNemHNdOLP/1JvcDJHWcNIl/wTpCUA1CCx4GAoyvxY/NIuWu//Mvql7iUUpPWS3fIL4I e1yp3TJA==; Original-Received: from cpc14-benw10-2-0-cust305.16-2.cable.virginm.net ([92.234.125.50]:34040 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 1bwlf2-001U2z-4K; Wed, 19 Oct 2016 08:51:40 +0100 In-Reply-To: <8360opwjs2.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 18 Oct 2016 22:15:41 +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:208459 Archived-At: Eli Zaretskii writes: >> From: Achim Gratz >> Date: Tue, 18 Oct 2016 20:48:29 +0200 >> >> Eli Zaretskii writes: >> > That just means installing a new version needs to remove the previous >> > version's files first, that's all. It has nothing to do with >> > load-path. >> >> That's simply not an option when a user wants to install an updated ELPA >> package in his home directory while the system administrator keeps the >> Emacs installation as-distributed. In other words, you'd kill _the_ >> feature that package.el was supposed to give mere users and arguably the >> main selling point. > > If no better solution comes up, it would mean the user will have to > restart Emacs. Hardly a catastrophe. Eli, I think you are not taking the time here to understand the problem. Both Achim and I have thought the issue through, and it restarting Emacs were the solution then neither of us would, I expect, be complaining. As Achim says, an org-html in the core installation cannot be removed because it comes as part of a packaged Emacs and needs admin privilleges; again, can be done, but not very good practice. The org-html in core can be shadowed but only by another file called org-html. More recent versions of org do not contain such a file. There are solutions to this, many of them hacky. The simplest solution is to NOT include the directory containing the old version of org in the load-path. Currently, package.el does not do this for core installed files, but does do this for package.el installed files. And, package.el could *only* be made to do this, if a package is in its own directory. >> But in the situation explained by Phillip it _is_ loadable, even though >> it must not be. If in fact you have an autoload pointing to a file that >> no longer exists or doesn't contain the autoloaded function anymore, >> then a modification of load-path after that autoload has been generated >> won't help at all. > > Restarting Emacs will solve that. It will not, and does not. >> If you think you don't need this, I have done some experiments to excise >> the remnants of a built-in package from Emacs' data structures >> (autoloads and customization), but there really isn't any supported way >> to do that and I consider the whole thing incredibly brittle since I >> need to manipulate internal data structures to do that. At the minimum >> you'd need official support for re-defining an autoload so it stops >> pointing at the wrong load-file. > > These problems need to be attacked and solved. But saying that > instead of solving them we should fundamentally change our lisp/ tree > is IMO not the right way. It's akin to searching the keys where the > streetlight is, not where they were lost. We need to define the goal, > and then work towards implementing it, not the other way around. I have defined my goal and a path toward it. I believe that Emacs should have a single mechanism for managing packages, and that this mechanism is package.el. I am aware that this is a big change and have, therefore, presented an incremental path by which this can be trialed out without mass renaming or moves of files in core, and which also allows support for adding packages stored in ELPA to the core build which is a sensible goal put forward by John. I will leave it there. If neither you or John want to go this way, I will stop. Phil