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: Wed, 19 Oct 2016 11:28:03 +0300 Message-ID: <83shrsvj3g.fsf@gnu.org> 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> <8760oosrn8.fsf@russet.org.uk> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1476865753 16136 195.159.176.226 (19 Oct 2016 08:29:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2016 08:29:13 +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 Wed Oct 19 10:29:09 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 1bwmF4-0001vT-9N for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 10:28:54 +0200 Original-Received: from localhost ([::1]:46305 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwmF6-0006ju-EI for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 04:28:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwmEZ-0006jZ-Kq for emacs-devel@gnu.org; Wed, 19 Oct 2016 04:28:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwmEV-0007qr-Ch for emacs-devel@gnu.org; Wed, 19 Oct 2016 04:28:23 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48739) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwmEV-0007qf-8w; Wed, 19 Oct 2016 04:28:19 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2802 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bwmEU-0007My-AG; Wed, 19 Oct 2016 04:28:18 -0400 In-reply-to: <8760oosrn8.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:208463 Archived-At: > From: phillip.lord@russet.org.uk (Phillip Lord) > Cc: Achim Gratz , emacs-devel@gnu.org > Date: Wed, 19 Oct 2016 08:51:39 +0100 > > 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 Those kinds of remarks are hardly constructive. Please assume that I've thought the issues through as best I could, and if I'm missing some important details, those details should be put on the table explicitly and discussed. > and it restarting Emacs were the solution then neither of us would, > I expect, be complaining. I don't see why restarting won't be a solution. If load-path was re-arranged to put the latest version of a package first, and the package's autoloads are on a file that has been regenerated, what else is missing to make restart the correct solution? > 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. If load-path is rearranged when a newer version of Org is installed, and org-loaddefs are regenerated, then, after a restart, any 'load' and 'require' will find the new files first, and the old ones will be effectively invisible to Emacs. Right? > 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. That solution will only work for packages in their own directories. We want to have a solution that works even for files in common directories. I think rearranging load-path and regenerating the autoloads will solve that as well. > >> 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. Why won't it? (The "does not" part just means package.el doesn't currently do that, AFAIU, but it can be extended to do it.) > 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. I think we both indicated that we want to go this way, we just don't want the Lisp files scattered among dozens of directories, each one with a single file. Yes, this is a goal that is harder to achieve, but I don't yet see any fundamental difficulties on that path, just some more work. I think making such a change incrementally is worse than doing it at once, as far as the directory structure is concerned. We don't want to change the directory structure several times, ideally not even once. But if some change is required, it should be done in one go, so we need to decide on the structure up front. Thanks.