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:51:15 +0300 Message-ID: <838ttjv7h8.fsf@gnu.org> References: <20160916203414.25203.87032@vcs.savannah.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> <86funsqij1.fsf@realize.ch> <87d1iw6t15.fsf@Rainer.invalid> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1476946355 4354 195.159.176.226 (20 Oct 2016 06:52:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 20 Oct 2016 06:52:35 +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:52: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 1bx7Cv-0005zX-B3 for ged-emacs-devel@m.gmane.org; Thu, 20 Oct 2016 08:52:05 +0200 Original-Received: from localhost ([::1]:52754 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bx7Cx-0003CD-L7 for ged-emacs-devel@m.gmane.org; Thu, 20 Oct 2016 02:52:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33081) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bx7CN-0003C7-Kt for emacs-devel@gnu.org; Thu, 20 Oct 2016 02:51:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bx7CK-00076A-IZ for emacs-devel@gnu.org; Thu, 20 Oct 2016 02:51:31 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39141) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bx7CK-000765-FY; Thu, 20 Oct 2016 02:51:28 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4633 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bx7CJ-0005Dl-Og; Thu, 20 Oct 2016 02:51:28 -0400 In-reply-to: <87d1iw6t15.fsf@Rainer.invalid> (message from Achim Gratz on Wed, 19 Oct 2016 21:24:54 +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:208522 Archived-At: > From: Achim Gratz > Date: Wed, 19 Oct 2016 21:24:54 +0200 > > Alain Schneble writes: > > Of course. The order of directories in load path is always relevant. > > Whatever structure we choose. > > Good. Now take that last step: if you want to be sure that you don't > load something you don't want to be loaded, it must not be found via > load-path at all times during the lifetime of the Emacs process. That is inaccurate. The accurate description would be "it must either not be found via load-path, or not mentioned in any 'load' and 'require' form and in any autoload cookie. > That precludes almost all solutions that depend on removal or > shadowing during later steps in the initialization sequence and > where not-yet-to-be-initialized packages become visible when > initializing another package. I don't see how you jump to that conclusion, except by assuming some buggy or chaotic behavior on some other packages. But we are not talking here about some obscure package downloaded from some github spot. We are talking about packages that today live in core, and will (or at least should) still get the same amount of attention from the Emacs developers when they are maintained on ELPA as they do today. So any assumptions of gross bugs like the ones you evidently have in mind in those packages are simply invalid. I understand you have bumped into such problems, and I understand that they could happen, but I disagree that we should account for them happening in the packages that are the subject of this discussion for longer than a few hours, exactly like we have today with any commit that breaks some build somewhere. Errors do happen, but if they are fixed soon enough, the design doesn't have to take these errors into consideration, and doesn't have to be robust against them. (It is, of course, nice to have such robustness where it comes for free or for a very low price, but not where the price is high.)