From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alain Schneble Newsgroups: gmane.emacs.devel Subject: Re: feature/integrated-elpa 4f6df43 15/23: README added Date: Wed, 19 Oct 2016 23:17:58 +0200 Message-ID: <86twc8ox6h.fsf@realize.ch> References: <20160916203414.25203.87032@vcs.savannah.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> <87k2d4fk9m.fsf@russet.org.uk> <83h988uzpm.fsf@gnu.org> <87eg3ce2s1.fsf@russet.org.uk> <87pomw8ces.fsf@lifelogs.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1476911998 2427 195.159.176.226 (19 Oct 2016 21:19:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2016 21:19:58 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (windows-nt) Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 19 23:19:50 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 1bwyGw-0006Ur-0x for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 23:19:38 +0200 Original-Received: from localhost ([::1]:51240 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwyGy-0002pL-9h for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 17:19:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwyGG-00027E-AK for emacs-devel@gnu.org; Wed, 19 Oct 2016 17:19:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwyGB-0003Ca-Gx for emacs-devel@gnu.org; Wed, 19 Oct 2016 17:18:56 -0400 Original-Received: from clientmail.realize.ch ([46.140.89.53]:4988) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bwyGB-0003AV-3f for emacs-devel@gnu.org; Wed, 19 Oct 2016 17:18:51 -0400 Original-Received: from rintintin.hq.realize.ch.lan.rit (Unknown [192.168.0.105]) by clientmail.realize.ch with ESMTP ; Wed, 19 Oct 2016 23:18:04 +0200 Original-Received: from myngb (192.168.66.64) by rintintin.hq.realize.ch.lan.rit (192.168.0.105) with Microsoft SMTP Server (TLS) id 15.0.516.32; Wed, 19 Oct 2016 23:17:57 +0200 In-Reply-To: (Lars Ingebrigtsen's message of "Wed, 19 Oct 2016 22:41:41 +0200") X-ClientProxiedBy: rintintin.hq.realize.ch.lan.rit (192.168.0.105) To rintintin.hq.realize.ch.lan.rit (192.168.0.105) X-detected-operating-system: by eggs.gnu.org: Windows NT kernel [generic] X-Received-From: 46.140.89.53 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:208509 Archived-At: Lars Ingebrigtsen writes: > Anyway, I've been trying to follow this discussion, and I just don't > seem to get what the problem is. Me too. > Now, package.el knows that the user wants foo-0.6, so it prepends that > directory to load-path. In addition, it also has to blacklist all .el > files from previous versions of the package that are visible, which > will, in this case, be the files in the manifest from the build-in > version 0.5. So it'll add '("lisp/foo.el" "lisp/image/foo-images.el") > to a new variable load-path-blacklist, and saying `(require 'foo-images)' > anywhere will fail with "cannot open load file". Do you really see a need for doing this? Either is foo-images some package-internal feature. Then nobody should care about it and no one should ever require it beside the old version of the package itself. Or it belongs to a public "API" that clients (whether packages or not) may use at will. But then foo package should account for it and somehow explicitly mark it as deprecated before removing the feature/file in a v1+n version. (Maybe package.el should support explicit withdrawal of a formerly published public feature. I'm not sure if a solution at the load-path "low-"level would be TRTTD.) Alain