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: Wed, 19 Oct 2016 20:26:33 +0200 Organization: Linux Private Site Message-ID: <87k2d46vqe.fsf@Rainer.invalid> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1476901662 5068 195.159.176.226 (19 Oct 2016 18:27:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2016 18:27:42 +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 Wed Oct 19 20:27:37 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 1bwvaN-0008OV-SF for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 20:27:32 +0200 Original-Received: from localhost ([::1]:50352 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwvaQ-0003hx-5M for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 14:27:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwvZr-0003hJ-Sy for emacs-devel@gnu.org; Wed, 19 Oct 2016 14:27:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwvZn-0007Q7-Tb for emacs-devel@gnu.org; Wed, 19 Oct 2016 14:26:59 -0400 Original-Received: from [195.159.176.226] (port=37388 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bwvZn-0007Nd-Mg for emacs-devel@gnu.org; Wed, 19 Oct 2016 14:26:55 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1bwvZf-00032x-Is for emacs-devel@gnu.org; Wed, 19 Oct 2016 20:26:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 75 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:Z2oRTHOUBRZDwN/xkBYI9TaKRbM= 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:208487 Archived-At: 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. This is not hypothetical, all of that has already happened and users have suffered from it. When they report the resulting symptoms it is extremely difficult to tease out what exactly happened, in which order and why, so it also wastes the time of those folks who want to help them. > 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. > 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. 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). 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 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. 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 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. 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. Single-file packages would live in one directory together, and multi-file packages would be in their own directory each. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada