From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: Core ELPA was: Testing fontification, indentation, and buffer manipulation Date: Mon, 11 Mar 2019 22:46:52 +0000 Message-ID: <87sgvtni5f.fsf@russet.org.uk> 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="254264"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.92 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 12 00:06:42 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 1h3U0G-0013xN-Rh for ged-emacs-devel@m.gmane.org; Tue, 12 Mar 2019 00:06:41 +0100 Original-Received: from localhost ([127.0.0.1]:41741 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h3U0F-00062B-RL for ged-emacs-devel@m.gmane.org; Mon, 11 Mar 2019 19:06:39 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:45998) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h3TuT-0000lV-AJ for emacs-devel@gnu.org; Mon, 11 Mar 2019 19:00:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h3ThC-0008Do-KW for emacs-devel@gnu.org; Mon, 11 Mar 2019 18:47:00 -0400 Original-Received: from cloud103.planethippo.com ([78.129.138.110]:38558) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h3ThB-0008CP-H5 for emacs-devel@gnu.org; Mon, 11 Mar 2019 18:46:58 -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:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vp1cwF9ICXdyJgTH/ebGxeK9viQYxXk9IX14/vk9AdE=; b=AL2zW6eZE09UygS3ITOyZG0zv WGz5legmV21ojsMTbccDgYwwU0IJ6iwMPCwtwWot5dwS/lZ1Jt6HOw+ejZyq9LKJIZdo2MMdACRZW QO1ZZAQPEjQdyEDBWj/65MrSlwLIJZR9Z+WSMFF0UsdYzQMIVCuPz6I9KzMoDWEAHz5ZW4k70CMlv dgLl3y7ZgjgQ1XqK/hqly5j5y+cftlJl8fT2qONqeyiPsQyhwvOVCUB1v/Y8LrCj36j64W6CjH4Y8 uB7l7dB2/Ap0s5l0x+0OKn4RRz+KucY5hTzA1+GwILuCpJV6dD2KB5Zo/55y4T+jq2VpLBrw2ORJ+ nKQiPz3oQ==; Original-Received: from cpc142652-benw12-2-0-cust953.16-2.cable.virginm.net ([82.21.43.186]:38484 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h3Th7-0003cw-KS; Mon, 11 Mar 2019 22:46:54 +0000 In-Reply-To: (Stefan Monnier's message of "Sun, 10 Mar 2019 14:02:28 -0400") 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 2.2.x-3.x [generic] X-Received-From: 78.129.138.110 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:234082 Archived-At: Stefan Monnier writes: >>> 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). Yes, that would also work and would be close enough not to worry me. >> 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. Yes, could do, although it would put slightly more work on the user. Having said that, (one of) the point behind this is to make packages in the default download easier to update, so you'd probably have to ask this anyway. >>>> 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. Namespaces can get messed up, people can use them wrong. With an SHA key, you don't have to worry about getting the naming scheme right (or indeed read the documentation on the naming scheme. You just use something that you, by definition, have anyway. > >> 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. ] I think this all sounds entirely reasonable. > 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. It would depend exactly how this was implemented I think. I would not want this to always work -- I mean, if someone gets it wrong and types "bundled/company/emacs27" (missing the dash) as their tag, having an automatic fallback will mean this form of error is not picked up. >> 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 I really struggle with this, to be honest, and cannot see how it is nicer. The key difference between a configure option is that you enable it once and then it is automatic (and breaks on failure). With a make target, you have to run it periodically at unpredictable times because you don't know when it's needed. For me, warning messages are likely to be lost in the haze of make -j 40. The only good time it seems easier is stuck on a plane without network. With your system, you just don't run "make update-elpa". With mine, you have to run ./configure (forcing a recompile) at the start of the flight and ./configure --enable-elpa at the end. >>> 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. As always, your greater knowledge on these things is happily accepted. > > FWIW, seq.el *is* (and always has been, IIRC) in core. Yes, this is correct. IIRC, though, for a while it was in the Emacs on master, rather than in a released version, and in ELPA for the current release. > 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). Possible, of course, but I'd have to build knowledge of assess into the test apparatus to do that, I think. Probably easier to go the seq.el route and install it into ELPA and core. Phil