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: Tue, 18 Oct 2016 14:11:24 +0300 Message-ID: <83vawpx677.fsf@gnu.org> References: <20160916203414.25203.87032@vcs.savannah.gnu.org> <831szrhwsr.fsf@gnu.org> <8760p12qzw.fsf@russet.org.uk> <83vax0en1u.fsf@gnu.org> <87pon5ek3q.fsf@russet.org.uk> <87twcgttjf.fsf@russet.org.uk> <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1476789357 7674 195.159.176.226 (18 Oct 2016 11:15:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 18 Oct 2016 11:15:57 +0000 (UTC) Cc: Stromeko@nexgo.de, emacs-devel@gnu.org To: phillip.lord@russet.org.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 18 13:15:52 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 1bwSMu-0000Hq-E9 for ged-emacs-devel@m.gmane.org; Tue, 18 Oct 2016 13:15:40 +0200 Original-Received: from localhost ([::1]:40408 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwSMw-0000Ja-HB for ged-emacs-devel@m.gmane.org; Tue, 18 Oct 2016 07:15:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47177) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwSJ8-0006Qr-2T for emacs-devel@gnu.org; Tue, 18 Oct 2016 07:11:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwSJ4-00041k-T7 for emacs-devel@gnu.org; Tue, 18 Oct 2016 07:11:46 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33127) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwSJ4-00041c-Qt; Tue, 18 Oct 2016 07:11:42 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4773 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bwSJ3-0005ye-UO; Tue, 18 Oct 2016 07:11:42 -0400 In-reply-to: <87eg3ekjz2.fsf@russet.org.uk> (phillip.lord@russet.org.uk) 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:208408 Archived-At: > From: phillip.lord@russet.org.uk (Phillip Lord) > Cc: Stromeko@nexgo.de, emacs-devel@gnu.org > Date: Tue, 18 Oct 2016 11:52:17 +0100 > > > That's exactly what I meant: we can do this with any directory > > structure. IOW the directory structure is not relevant to this issue. > > I think that this is incorrect. In this case, we can do this with the > directory structure that we have at the moment, and for org-mode, > because org-mode is a) in a directory of it's own and b) has it's own > loaddefs. This is not true for many of the files in ./lisp. When I said "we can do this" I didn't mean "without any changes" or "for free". We will have to make changes, both in how loaddefs are generated, and in the build. My point is that these changes are not difficult, since we already do that for several distinct packages in the core. We just need to do that for more packages, that's all. > The point here is that load-path is *directory* based. As it stands, we > cannot exclude some files in one directory. I don't see any need to exclude files. If a newer version of a package is installed outside of the Emacs lisp/ tree, the directory of that package needs to be earlier in load-path than the main lisp/ directory and its subdirectories. Again, not hard to arrange. > > So one solution would be to provide a separate autoloads file for each > > package that lives on ELPA. That again has nothing to do with the > > directory structure. Right? (There could also be other solutions.) > > I think that it is evident that there could be other solutions. Emacs is > Turing complete so any computable solution that you can image is > possible. The question is which is easiest. They are all easy. > package.el already does all of this. Once again, package.el in its current form was never meant to be used in the capacity we are talking about. So using it without changes for the job we are discussing is wrong, because it would mean to subdue our directory organization to decisions made for a completely different use case. In any case, such a solution was already rejected, both by John and myself. So let's not argue about this anymore; let's instead see which changes are needed in package.el to support the preferred directory structure in core, even when some of the bundled packages live on ELPA. > >> There are a few other things that package.el does, which it would be > >> shame to loose. It checks dependencies for instance. So, say, I > >> installed assess.el into Emacs core using package.el as I suggest, and > >> it requires a newer version of seq.el than is available, package.el will > >> bitch about this very early. > > > > I don't see why we'd have to lose this. No one said we are throwing > > away package.el. We are talking about _extending_ it. > > Just so that we can keep a particular directory structure? Yes! > > We need to adapt package.el to the new needs. It was not written with > > these goals in mind, so it needs to learn new tricks. Throwing it > > away is not acceptable, but neither is blindly accepting its current > > assumptions, which were not designed for the use case we are > > discussing. > > No, but it's current behaviour makes a lot of sense to me and is, I > think, better than the monolithic structure we have in ./lisp. Others, including myself, disagree.