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: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added Date: Mon, 10 Oct 2016 09:23:56 +0300 Message-ID: <83wphgen7n.fsf@gnu.org> References: <20160916203414.25203.87032@vcs.savannah.gnu.org> <871t0apsxm.fsf@russet.org.uk> <87shsm7hi6.fsf@russet.org.uk> <83a8eucwi2.fsf@gnu.org> <878tudgwlq.fsf@russet.org.uk> <8360pgoyo4.fsf@gnu.org> <87d1jn3ws9.fsf@russet.org.uk> <83a8eqoi08.fsf@gnu.org> <87d1jlacsh.fsf@russet.org.uk> <867f9t4n4t.fsf@realize.ch> <874m4x8sq5.fsf@russet.org.uk> <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> <87a8ed2r73.fsf@russet.org.uk> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1476080705 26775 195.159.176.226 (10 Oct 2016 06:25:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 10 Oct 2016 06:25:05 +0000 (UTC) Cc: a.s@realize.ch, monnier@iro.umontreal.ca, 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 Mon Oct 10 08:24:58 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 1btU0l-00034T-Gi for ged-emacs-devel@m.gmane.org; Mon, 10 Oct 2016 08:24:31 +0200 Original-Received: from localhost ([::1]:47743 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btU0j-00087k-Tq for ged-emacs-devel@m.gmane.org; Mon, 10 Oct 2016 02:24:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btU05-00086P-9O for emacs-devel@gnu.org; Mon, 10 Oct 2016 02:23:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btU02-00017C-2M for emacs-devel@gnu.org; Mon, 10 Oct 2016 02:23:49 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43319) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btU01-00016J-VN; Mon, 10 Oct 2016 02:23:46 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1896 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1btTzz-0008OV-6p; Mon, 10 Oct 2016 02:23:43 -0400 In-reply-to: <87a8ed2r73.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:208138 Archived-At: > From: phillip.lord@russet.org.uk (Phillip Lord) > Cc: a.s@realize.ch, monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Sun, 09 Oct 2016 21:38:40 +0100 > > Eli Zaretskii writes: > >> Packages in already in package.el format can be directly used within > >> Emacs. > > > > What do you mean by "directly used"? Directly as opposed to what? > > Without installation -- that is, as part of core emacs. What do you mean by "installation" in this case? Copying each file to its place, as opposed to just replicating the same directory structure? Or do you mean something else? > >> This requires no changes in the file layout, and means that > >> packages will only be built with a single system (i.e. both Emacs core > >> and ELPA will be build with package.el). > > > > Why would the Emacs build require package.el to do anything at all? > > Why not? It's a convienient way of building packages. If that convenience comes at a price of making our directory structure harder to work with, it's more like INconvenience. > > And what kind of build do you have in mind here? We have: > > > > . build out of Git repo > > . build of the release tarball as distributed from ftp.gnu.org > > . build of the release tarball after updating some packages from ELPA > > All of these, I think. Each one could have a separate solution. For example, the first one could be done with Git commands, bypassing package.el entirely, or with Git commands followed by something that package.el does to populate the right directories. > > ELPA packages should be logically part of Emacs, just in a different > > Git repo. So this goal should be supported, of course. But I don't > > understand why it would require using a separate directory tree for > > ELPA packages. > > It enables the convienience of taking a directory containing a package > from ELPA and putting it within the Emacs build unchanged. This seems > clean and simple. It should also enable "git submodule/subtree" type > options. See above: it could be easy to do, but be a nuisance in the long run. So it is IMO incorrect to consider only the short-term convenience of putting together the necessary machinery, we need to consider the long-term convenience as well, if not first of all. > >> It also, of course, means that files from ELPA would now be duplicated > >> in core Emacs because they would have been copied. > > > > ??? Copied from where to where? And why? I don't understand why they > > would need to be copied anywhere, they just need to be downloaded > > directly to where they belong in the Emacs directory structure. > > Downloading is copying right? That price cannot be avoided, since ELPA is a different repository. Right? > >> So, when developing Emacs, there would be version controlled .el > >> source files and non-version controlled copied .el files in the same > >> location. > > > > We already have that; see charscript.el. Why having some moe > > unversioned *.el files would hurt or be any different? > > There are generated .el files in Emacs, and there are specific cases > where this is necessary, but it's not a great thing. Mostly, I think, > .el files should be source code. At the moment, it's only a few files. > Making this more common seems bad. I disagree. I see no reason to consider generated files "bad". And there's no fundamental difference between generating them by C or Lisp programs and "generating" them by using Git commands. > >> You would have to remember to edit the former, but not the latter. > > > > ??? Unversioned files can be edited to your heart's content, they will > > just be overwritten on the next update. > > Yep, which is bad, if you didn't intend this to happen. We deal with this "badness" every day. So I think this is a downside that is very minor and can be disregarded when more serious issues are at hand.