From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: feature/integrated-elpa 4f6df43 15/23: README added Date: Sat, 15 Oct 2016 12:48:17 +0100 Message-ID: <8760ot7rzy.fsf@russet.org.uk> References: <20160916203414.25203.87032@vcs.savannah.gnu.org> <8637kh4j1u.fsf@realize.ch> <87wpht4b1i.fsf@russet.org.uk> <86y4292m2u.fsf@realize.ch> <8737kd8vfh.fsf@russet.org.uk> <867f9n2r6s.fsf@realize.ch> <87a8egw2az.fsf@russet.org.uk> <8360p3i2gt.fsf@gnu.org> <86a8efqf9p.fsf@realize.ch> <8337k7hysd.fsf@gnu.org> <8660p3qd99.fsf@realize.ch> <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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1476532180 25915 195.159.176.226 (15 Oct 2016 11:49:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 15 Oct 2016 11:49:40 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Andy Moreton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 15 13:49:36 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 1bvNSj-0003Kg-UT for ged-emacs-devel@m.gmane.org; Sat, 15 Oct 2016 13:49:14 +0200 Original-Received: from localhost ([::1]:51410 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bvNSi-0000Bq-Jn for ged-emacs-devel@m.gmane.org; Sat, 15 Oct 2016 07:49:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bvNSb-0000Ba-WD for emacs-devel@gnu.org; Sat, 15 Oct 2016 07:49:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bvNSX-0007Y5-Qk for emacs-devel@gnu.org; Sat, 15 Oct 2016 07:49:04 -0400 Original-Received: from cloud103.planethippo.com ([31.216.48.48]:54483) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bvNSX-0007GF-GB for emacs-devel@gnu.org; Sat, 15 Oct 2016 07:49:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From; bh=XAFwR+KRbtS4oqHp/H3y6+ticWvx+ajKSsRBph+nqOU=; b=P/jy0k/UImgkFB53Nri/CyySYB w5o0MLkCUvGJIf88THZqjkCcOV8i02TUBR4u/dvFE0Ofkf18GRiU/1oErjPymVeuYrJ+aXKSxNCyq TVz1IRdvvKcgV+ztftXnpGN0/tg+iltHAF51izDabX4dFEumPoB6b+6FPoXbFK8874caLRO1gAGHK FOccMaEU8nN1rONOqjsQSXJTrOtMroFDO4lU8avtheX/RW7xk5SnQ9DNIXmA9+G2Q/hGQsyaPWU19 sS4YZcSYwLygCffSiQV8c7VISNH76SEptfLJQGjzBJU5A1sVYT+F7MRogWPUz1vv/iINrAOvc4nZC EUxNwlwA==; Original-Received: from cpc14-benw10-2-0-cust305.16-2.cable.virginm.net ([92.234.125.50]:50084 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1bvNRr-004KKP-1h; Sat, 15 Oct 2016 12:48:19 +0100 In-Reply-To: (Andy Moreton's message of "Fri, 14 Oct 2016 14:51:15 +0100") X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud103.planethippo.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - russet.org.uk X-Get-Message-Sender-Via: cloud103.planethippo.com: authenticated_id: phillip.lord@russet.org.uk X-Authenticated-Sender: cloud103.planethippo.com: phillip.lord@russet.org.uk X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 31.216.48.48 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:208283 Archived-At: Andy Moreton writes: >> But Org already supports those two formats. We don't require Org to >> do anything that it doesn't already do. So staying with the current >> structure of lisp/ in the Emacs tree doesn't add any new requirements. > > But that would do nothing to reduce the unnecessary and duplicated > packaging work. > > Keeping each package in ELPA format ensures that replacing the package > can be done easily, as everything is isolated in a single directory. If > the package is shipped in the emacs tarball and the user then upgrades > to a newer version from ELPA, only the load path needs to change. Yes, this is precisely my argument. Each elisp package should be packaged in one and only one way and used in this way. Anything else adds complexity for the developers of that package that is unfortunate. Given that package.el provides a packaging solution that we already use, adding it to the core build enables this simply and straightforwardly. > In additon, the user can easily compare the changes bewteen the package > version shipped in the emacs tarball and the updated one fetched from > ELPA, as the package layout is the same. > > There are many more users of emacs than developers, so the design > should be aimed at utility and convenience for users. In this case, I am not sure this is so relevant; or, rather, it is highly dependent on what you mean by "users". My belief is that the real end users should see no difference at all. So the cost-benefit is between the developers of individual packages, the developers of core Emacs, and the developer of the build system. My belief is that the first group win without cost from my proposal. The second group, I think also win, especially if we can use some git cleverness to make the core and tarball ELPA packages easy to update via vc (i.e. some git submodule type of thing). And for the latter, it's not clear; we have to offset getting package.el into the build system (which I have proof of principle), against that of moving files around the source tree, then building as usual. Phil