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: Thu, 20 Oct 2016 09:35:08 +0300 Message-ID: <83bmyfv883.fsf@gnu.org> References: <20160916203414.25203.87032@vcs.savannah.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> <83shrsvj3g.fsf@gnu.org> <87k2d46vqe.fsf@Rainer.invalid> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1476945386 29736 195.159.176.226 (20 Oct 2016 06:36:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 20 Oct 2016 06:36:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Achim Gratz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 20 08:36:23 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 1bx6xL-0004hv-Qc for ged-emacs-devel@m.gmane.org; Thu, 20 Oct 2016 08:35:59 +0200 Original-Received: from localhost ([::1]:52691 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bx6xN-0004dl-P7 for ged-emacs-devel@m.gmane.org; Thu, 20 Oct 2016 02:36:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53334) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bx6wn-0004df-Rx for emacs-devel@gnu.org; Thu, 20 Oct 2016 02:35:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bx6wi-0006ra-OH for emacs-devel@gnu.org; Thu, 20 Oct 2016 02:35:25 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38881) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bx6wi-0006rW-LG; Thu, 20 Oct 2016 02:35:20 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4616 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bx6wh-0003KK-Up; Thu, 20 Oct 2016 02:35:20 -0400 In-reply-to: <87k2d46vqe.fsf@Rainer.invalid> (message from Achim Gratz on Wed, 19 Oct 2016 20:26:33 +0200) 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:208521 Archived-At: > From: Achim Gratz > Date: Wed, 19 Oct 2016 20:26:33 +0200 > > Eli Zaretskii writes: > > 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? > > You are missing that the order in which all these things happen becomes > important. The newer autoload can only shadow the old one if it's > processed _before_, likewise initializing other Emacs packages might > inadvertently pull in old autoloads or definitions before things have > been rearranged by package.el. I understand that. I just don't see why we couldn't do this in the correct order, given that the meta-data which accompanies the update of a package is correct. > > 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? > > If you only want to look at that one-dimensional example, yes. Real > Emacs installations are quite a bit more varied. The tools we have > today to sove this problem make things more brittle when they should > become more robust. I understand that in general having some bundled packages in another repository makes things more complex, perhaps much more complex. But since the majority wants that, we will have to deal with that complexity and solve it well enough to work in practice. > I still don't get what you hope to gain from throwing things that don't > belong together (and aren't upstrem) in a single directory (only talking > about the code parts here, documentation can be pulled someplace else). Simplicity of use for everyone and transparency for end users (who shouldn't be concerned in which Git repo a given package is maintained). > In fact, most of the packages that might be on ELPA already are in their > own subdirectories and the only thing you'll need to do is not generate > the first-level autoloads into loaddefs.el and instead have some > package-autoloads be generated by package.el. Then create some default > package configuration with all these packages activated, but give the > user configuration preference so they can be deactivated. I see no reasons that this couldn't be done without having a separate directory per package. > Single-file packages in core that are duplicated on ELPA (if these even > exist, I haven't checked) can coexist just fine in a single directory if > you so desire. They are orders of magnitude less complicated to deal > with. But the total of these should still live in a separate package > directory that is created just to give them a home. I see no reasons to have a separate directory for packages that come bundled. > I've said it before and I will say it again just this one time: If Emacs > takes packetization of the core seriously, then the "hard core" should > contain just the stuff that is needed for bootstrapping Emacs. > Everything else should be a package. If you mean that those "packages" are downloaded by end users when they install Emacs, and don't come with the release tarball, then this is against the current agreements, AFAIU. The current agreements are that the ELPA packages are downloaded and installed in the Emacs tree when the release is being tarred, and come in the bundle ready to be used.