From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Core ELPA was: Testing fontification, indentation, and buffer manipulation Date: Sun, 10 Mar 2019 14:02:28 -0400 Message-ID: References: <7803c5de-e139-01ed-e9e3-98abb875782b@grinta.net> <2d777e7b-28d9-36a5-073d-b439fca9706a@grinta.net> <1548067539.3478998.1639830432.03003247@webmail.messagingengine.com> <87bm47558t.fsf@russet.org.uk> <87pnsm2vsm.fsf@russet.org.uk> <878sz7u2f5.fsf@russet.org.uk> <87o976p6xt.fsf_-_@russet.org.uk> <87tvgm7fnu.fsf@russet.org.uk> <87sgw6i89k.fsf@russet.org.uk> <875zt15y0x.fsf@russet.org.uk> <87sgw3bzod.fsf@russet.org.uk> <87r2bfx89o.fsf@russet.org.uk> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="205660"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 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 Sun Mar 10 19:07:52 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h32rY-000rQ0-4m for ged-emacs-devel@m.gmane.org; Sun, 10 Mar 2019 19:07:52 +0100 Original-Received: from localhost ([127.0.0.1]:47934 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h32rX-0005Zq-2c for ged-emacs-devel@m.gmane.org; Sun, 10 Mar 2019 14:07:51 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37052) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h32q4-0005Vd-07 for emacs-devel@gnu.org; Sun, 10 Mar 2019 14:06:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h32mO-0006Yk-9K for emacs-devel@gnu.org; Sun, 10 Mar 2019 14:02:33 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:50670) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h32mN-0006Y2-UT for emacs-devel@gnu.org; Sun, 10 Mar 2019 14:02:32 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x2AI2TEK022965; Sun, 10 Mar 2019 14:02:29 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id EB6976A17C; Sun, 10 Mar 2019 14:02:28 -0400 (EDT) In-Reply-To: <87r2bfx89o.fsf@russet.org.uk> (Phillip Lord's message of "Sun, 10 Mar 2019 11:45:39 +0000") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6499=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6499> : inlines <7030> : streams <1815320> : uri <2810328> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:234036 Archived-At: >>> I'm unconvinced. I think a build should be repeatable. Imagine bisecting >>> a bug that has come up in an ELPA package when you are not sure whether >>> it's the package or Emacs core that has broken things. >> >> That's already a problem with Elisp packages (whether from GNU ELPA or >> elsewhere), so the fact that we bundle some of them doesn't make much of >> a difference in this respect. > > It is, but, now that ELPA package will be in the tarball download; I > think when someone says "bug X, affecting package Y, in Emacs-26.Z" that > should give you enough information to try and reproduce the error. For the actual release, I'd expect the branch/tag to be very precise, indeed (maybe even an SHA at that point). > Without a repeatable build, you will also need to know what verison > package Y is, if and only if it is a "core ELPA" package. We could also consider such bug reports exactly like we do now: treat the bundled GNU ELPA packages as if they weren't bundled, and ask the user what is the version of the GNU ELPA package affected. >>> That might mean multiple branches of master which would produce a very >>> cluttered namespace. The problem is that ELPA currently uses a different >>> (non git) mechanism to identify the current version of every package; so >>> you can't identify this from git metadata (except for SHA!). >> I don't know what you mean. A branch/tag is just a name for an SHA, so >> I can't see why a branch/tag wouldn't work where an SHA does. > This is how a tag is implemented not what it is. A tag is a meaningful > name, living in a single namespace for an entire repository, which can > refer to different versions over time. A SHA key is not meaningful, > which while it lives in a single namespace has been written to attempt > to be world-unique, and cannot refer to different versions over time. I understand this difference but I don't see how it relates to what you said above. > I have extensive experience with naming schemes and "simply" is rarely a > term I would apply; especially, in this case, where many packages > inhabit a single namespace. This rules out the obvious scheme of just > using the Emacs version number. > My naming scheme would be to use a stable, meaningless identifier. I was thinking of something like "//" E.g. bundled/company/emacs-27 [ I had suggested that in addition to `emacs-27` we also create a branch `emacs-27.1` (created when we get into the final phase where we only allow commits that are explicitly allowed by the maintainer), so we could have bundled/company/emacs-27.1 as the branch pointing to the "final" version of company bundled with the Emacs-27.1 release. ] In order to reduce the number of such branches, we'd likely want some fallback scheme where we have "/" when "//" doesn't exist, and finally use just `master` when "/" doesn't exist either. > Regardless, the code works either way, because as you say an tag is > implemented as an SHA. Indeed. All this discussion is really about not needing to pull from the repository as part of a normal `make`, but moving this operation to a separate invocation explicitly requesting it (call it `make update-elpa` or something). > Currently, to achieve this on a clone of Emacs, you'd have to > reconfigure. With "./configure", my build would not install ELPA > packages and would (when I've written the code!) only produce a single > source tarball. With "./configure --enable-elpa", it would install ELPA > and produce two source tarballs, but would fail to build without ELPA. > > Happy to put another mechanism in, but not sure what that would be. Not sure what it should look like at the code level, but I think we could live without "./configure --enable-elpa". Instead, we'd have: git clone; ./configure; make build Emacs normally but including warnings about GNU ELPA packages not being found. git clone; ./configure; make update-elpa; make build Emacs with the all the bundled GNU ELPA packages. And subsequent git pull; ./configure; make will build with those same bundled GNU ELPA packages, potentially emitting some warnings about *some* GNU ELPA packages not being found. >> Maybe in the future, we'll want to allow some bundled-GNU-ELPA packages >> to be more important (e.g. be *necessary* for example because they're >> used by some core Elisp packages), but there's no need to cross that >> bridge now. > Ironically, the package that stimulated this discussion was > "assess.el" which is a testing package. From a user perspective, of > course, it makes no difference but for the developer it's exactly the > sort of package that you would want to make a dependency to many other > packages. Likewise, seq.el (which is why Nicolas wants to move it from > ELPA to core!). I know: I don't mean to rule out having GNU ELPA packages that are indispensable, but I think we should take it one step at a time, otherwise the whole thing might just be rejected. FWIW, seq.el *is* (and always has been, IIRC) in core. As for assess.el, having it in GNU ELPA is OK as long as it is not needed when *building* Emacs's core packages. Basically, it should be OK if we can do (like we do with ERT): `make lisp; make elpa; make tests` (tho we'll probably have to work extra to try and make sure that `make tests` nicely skips those tests that require assess.el when assess.el is missing). Stefan