From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: ELPA policy Date: Wed, 11 Nov 2015 06:58:02 -0800 (PST) Message-ID: References: <87ziyuaqhl.fsf@petton.fr> <87fv0labbf.fsf@web.de> <87y4eda0kl.fsf@petton.fr> <22074.42230.156669.584780@retriever.mtv.corp.google.com> <87ziyoxvdp.fsf@Rainer.invalid> <83k2psnzyh.fsf@gnu.org> <87mvuorz7n.fsf@gmail.com> <8337wfon3f.fsf@gnu.org> <56401834.8080402@yandex.ru> <83ziynma4s.fsf@gnu.org> <5640C6A0.5010709@yandex.ru> <83twovm9es.fsf@gnu.org> <868u65afvh.fsf@stephe-leake.org> <86ziyl8ote.fsf@stephe-leake.org> <95e718da-7704-42b9-b327-cadd98b4e6f3@default> <86fv0c6gq6.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1447253926 25541 80.91.229.3 (11 Nov 2015 14:58:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Nov 2015 14:58:46 +0000 (UTC) Cc: John Wiegley , emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 11 15:58:35 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZwWr2-0003gH-DE for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 15:58:32 +0100 Original-Received: from localhost ([::1]:41087 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwWr1-0002pd-Ry for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 09:58:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwWqk-0002pV-FN for emacs-devel@gnu.org; Wed, 11 Nov 2015 09:58:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwWqc-0005lO-47 for emacs-devel@gnu.org; Wed, 11 Nov 2015 09:58:14 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:32281) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwWqb-0005l8-Tm for emacs-devel@gnu.org; Wed, 11 Nov 2015 09:58:06 -0500 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tABEw4lh004471 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Nov 2015 14:58:04 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tABEw4oQ025452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Nov 2015 14:58:04 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tABEw44F016309; Wed, 11 Nov 2015 14:58:04 GMT In-Reply-To: <86fv0c6gq6.fsf@stephe-leake.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194062 Archived-At: > > Here's a naive question regarding where you place Lisp code > > that is distributed with Emacs (part of the tarball): Will > > anything change for users, depending on where you happen to > > manage the code wrt ELPA etc.? > > > > I'm guessing (and hoping) not, so that the distributed > > directory structure will remain the same. Is that correct? >=20 > That's a good point. But I'm not clear what previous state you are > comparing to. Previous delivery of Emacs (back to ~Day One), including its source code, especially Lisp, under directory lisp/. What's unclear about that? > There are two cases; > 1) A package that is currently in Emacs git moves to Gnu ELPA git but > remains in the Emacs tarball. > 2) A package that is currently in Gnu ELPA git stays there, and is added > to the Emacs tarball. >=20 > I would argue that tarball ELPA packages should be installed in some > system level elpa directory (similar to the user's .emacs.d/elpa), not > in the main emacs/lisp install directory. You say you would argue that, but where's the argument? How about a reason? As one user, I would prefer that all distributed Lisp code be under lisp/. Makes things simpler for users (who might even have existing scripts etc. that expect this). Is there a good reason not to keep this behavior? I don't really care where you stick code, or how you access it, for development purposes. Where an Emacs distribution puts it for _users_ should remain what it has been, IMO, if possible - somewhere under lisp/, at least. Why should changes in where you keep code for development affect where users of Emacs find it? > I don't think the history of a package should determine where it is > installed. So in case 1), I expect the package to be in a different > installation directory from the previous Emacs release. But it's still > in the default load-path, so this change is transparent to the user. `load-path' is not everything, so no, it is _not_ transparent to users, depending on what they do and how they use Emacs (including its source code). Emacs should be able to present its source code to users in the same way as in the past, I would think. They certainly should not be _required_ to use the package system or git or ... to access it. `package.el' should be a nice-to-have. It should not become an obligatory hoop for users to jump through. Most users will find it handy, just as some users might find a menu handy. But it should not become a necessary way to access Emacs code. > But it's not too important; the important distinction is that tarball > ELPA packages are _not_ in the developer Emacs workspace, so core > code cannot accidently depend on them. That might be important to developers, but it is not the issue I asked about.