From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Achim Gratz Newsgroups: gmane.emacs.devel Subject: Re: feature/integrated-elpa 4f6df43 15/23: README added Date: Tue, 18 Oct 2016 20:48:29 +0200 Organization: Linux Private Site Message-ID: <878ttl3342.fsf@Rainer.invalid> References: <20160916203414.25203.87032@vcs.savannah.gnu.org> <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> <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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1476816635 17958 195.159.176.226 (18 Oct 2016 18:50:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 18 Oct 2016 18:50:35 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 18 20:50:31 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 1bwZSr-0002Li-Px for ged-emacs-devel@m.gmane.org; Tue, 18 Oct 2016 20:50:17 +0200 Original-Received: from localhost ([::1]:43324 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwZSt-0001Cf-Tp for ged-emacs-devel@m.gmane.org; Tue, 18 Oct 2016 14:50:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwZRi-0001AD-0S for emacs-devel@gnu.org; Tue, 18 Oct 2016 14:49:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwZRe-00062F-3t for emacs-devel@gnu.org; Tue, 18 Oct 2016 14:49:06 -0400 Original-Received: from [195.159.176.226] (port=50609 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bwZRd-000614-Sf for emacs-devel@gnu.org; Tue, 18 Oct 2016 14:49:02 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1bwZRM-00085B-5Y for emacs-devel@gnu.org; Tue, 18 Oct 2016 20:48:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 76 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:OWuZb3GaLX2YQlFuIR0Lxtpw0FQ= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:208439 Archived-At: 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. >> Org-mode v1 comes with org-html. v1 is distributed through ELPA. >> Org-mode v2 comes with ox-html. We upgrade v1 to v2, and v1 is removed >> from the path. org-html is no longer loadable. > > org-html doesn't need to be loadable if it doesn't exist in the new > version. Again, nothing to do with load-path. 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. >> My conclusion: having org-mode its own directory is a good thing. By >> extrapolation, therefore, having most or all packages in their own >> directory would be a good thing. > > The extrapolation is invalid, because while Org is a very large > package, most other packages aren't. Forget about Org. The only reason it gets mentioned at all is that it is moving fast enough to have already produced all the problems mentioned so far _in the wild_, with actual users suffering the consequences. Each such failure can be easily demonstrated with a package having just a single or two files. >> > If package.el already knows how to unload the old features and load >> > the new ones, it will continue doing this for any package, whether in >> > or out of core. Right? >> >> With the example that I have given, this fails at the moment for >> org-mode, specificially because org-mode is in core. > > I don't understand why it fails, but if it's a missing feature in > package.el or in the infrastructure, we need to add that, in order to > move to having bundled packages on ELPA. Well, start with cleaning up load-path and autoloads in a way that any built-in package can be cleanly deactivated: after deactivation Emacs behaves as if the package wasn't present. 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. Again, the results of those forays are still in (upstream) Org in various places: testing/org-batch-test-init.el removes enough of the Emacs' builtin Org package so that the tests actually use the correct files, there's some more code in mk/org-fixup.el to deal with the generation of some files that package.el can't produce in its current state and then some checks in org-version (org.el) to warn about a mixed installation. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds