From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mohsen BANAN Newsgroups: gmane.emacs.devel Subject: Re: Stability of core packages Date: Sat, 29 Apr 2023 14:47:51 -0700 Organization: ByStar Federation of Autonomous Libre Services -- http://www.by-star.net Message-ID: References: <87a5zj2vfo.fsf@gmail.com> <834jpifizy.fsf@gnu.org> <83y1mue1qi.fsf@gnu.org> <83sfd2e01f.fsf@gnu.org> <1a5e5837-513b-84d8-3260-cdbf42b71267@gutov.dev> <83sfcz9rf2.fsf@gnu.org> <09a49ab9-ac72-36a9-3e68-9c633710eba7@gutov.dev> <83r0sh8i1q.fsf@gnu.org> <35638c9d-e13f-fad8-5f95-ea03d65d4aa2@gmail.com> <87a5z3izst.fsf@web.de> <83v8hr7qk9.fsf@gnu.org> <871qkfirbl.fsf@web.de> <83ildr6qhu.fsf@gnu.org> <83bkj7qk4m.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10089"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1.50 (gnu/linux) Cc: emacs-devel@gnu.org, =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 30 07:15:03 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pszOp-0002RT-3N for ged-emacs-devel@m.gmane-mx.org; Sun, 30 Apr 2023 07:15:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pszNu-0001aD-Ux; Sun, 30 Apr 2023 01:14:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pssQC-0000te-NA for emacs-devel@gnu.org; Sat, 29 Apr 2023 17:48:00 -0400 Original-Received: from 0030.bacs.by-star.net ([198.62.92.180] helo=0027.bacs.by-star.net) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1pssQ9-0004LM-NK for emacs-devel@gnu.org; Sat, 29 Apr 2023 17:47:59 -0400 Original-Received: (qmail 3610 invoked from network); 29 Apr 2023 21:47:51 -0000 Original-Received: from 192.168.0.90 ([192.168.0.90]) by 0030.bacs.by-star.net ([198.62.92.180]) with ESMTP via TCP; 29 Apr 2023 21:47:51 -0000 In-Reply-To: <83bkj7qk4m.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 29 Apr 2023 09:26:33 +0300") Received-SPF: none client-ip=198.62.92.180; envelope-from=emacs@mohsen.1.banan.byname.net; helo=0027.bacs.by-star.net X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 30 Apr 2023 01:14:05 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:305725 Archived-At: Eli Zaretskii writes: >> From: emacs@mohsen.1.banan.byname.net >> Cc: "Dr. Arne Babenhauserheide" , joaotavora@gmail.com, >> jporterbugs@gmail.com, dmitry@gutov.dev, emacs-devel@gnu.org >> Date: Fri, 28 Apr 2023 22:21:46 -0700 >> >> >> I have been following this thread from a meta perspective. > > Thanks for chiming in. > >> Because we use git for everything and because it >> is possible to take complete git snap shots of all >> relevant packages, it is possible to easily >> provide stability for the user based on snapshots. >> >> Consistent upgrades are then possible for new >> consistent git snapshots. So, based on the snapshots >> the packages are not stale and remain consistent >> while evolving. >> >> This is what doomemacs does. For every package, >> there is a git tag which doomemacs keeps with the >> adoption of the package. The tags are guaranteed >> to be consistent. With Blee (ByStar Libre Emacs >> Environment) I do the same but instead of keeping >> that tag with the packages, I keep central >> manifests for emacs releases. So, emacs-28.1 has >> its own packages manifest which can be upgraded >> from time to time. All upgrades go to the >> appropriate repo and get the appropriate tag based >> on the manifest. I do this across all emacs >> package archives -- which I see as collections of >> git repositories. >> >> If you want to go with something like this, you >> have to revisit the package retrieval model. >> >> For every release of emacs, you maintain a >> separate manifest. And you keep updating that at >> new releases and even in between releases. Since >> all emacs archives are git based, it is possible >> to apply this strategy to all of them -- where >> each take care of its own consistency. > > I've read this several times, and I admit I still don't really > understand the suggestion. Maybe it's because you are using some > terminology without explaining it in enough details, perhaps because > you assume prior knowledge of what it means. Sorry about that. In fact, that is the case. I was assuming that you and others would be familiar with the lessons learned from the "straight.el" and doom emacs efforts over the past many years. My apologies. To better set the context, let me start with a quote from: https://github.com/doomemacs/doomemacs/blob/master/docs/faq.org ----------- Why does Doom use straight.el and not package.el? package.el simply doesn=E2=80=99t cut it. Its flaws become apparent the more packages you manage, the more complex your config becomes, and how often those packages see updates: - No Disaster recovery ... - Rolling release or bust package.el installs the latest version of every package, or none at all. There=E2=80=99s no rollback, no pinning to a stable ref, and no git history to peek into. It offers little reproducibility; wiping/losing/copying your config becomes a gamble if you aren=E2=80=99t constantly backing up your packages (then recompiling them if you=E2=80=99re up/downgrading Emacs). melpa-stable was well intentioned, but it offers no guarantees or standards on how/when maintainers tag their projects. I=E2=80=99d rather the user decide for themselves, because they=E2=80=99re the ones in the trenches. ... Package management needs to be easier, because Emacs is hard enough already. Doom fills these gaps with straight.el=E2=80=99s help, and beyond. ------------ I am not saying that everything that Henrik Lissner is saying is correct. But I also think that the model of package.el is inadequate and that it should be replaced by something like straight.el. The readme of https://github.com/radian-software/straight.el has a Guiding principles section. As Jo=C3=A3o T=C3=A1vora observes, straight.el can be a solution for the eglot use case: Jo=C3=A3o T=C3=A1vora> Who knows, maybe this will all be OK after all?? Hal= f the Jo=C3=A3o T=C3=A1vora> users are using "straight.el" anyway (and I really d= oubt Jo=C3=A3o T=C3=A1vora> it is hampered by these minutiae about dependencies,= seeing Jo=C3=A3o T=C3=A1vora> as MELPA-land is teeming with way more "dependency h= ell"). > > Here are some questions for which I didn't find answers, and which > precluded me from following your suggestions: > > . what is a "git snapshot"? what does it include in the context of > this discussion? By a "git snapshot" I mean a collection of Git commit IDs which can be used as pins. In the doom model, with streight.el and with the eglot use case, consider: (package! eglot :pin "e501275e06952889056268dabe08ccd0dbaf23e5") https://github.com/doomemacs/doomemacs/blob/master/modules/tools/lsp/packag= es.el That is an example of a git snapshot. > . what is meant by "upgrades for new consistent git snapshots"? how > is such an upgrade done, and how does it work in practice? New collection of Git commit IDs can then become basis for upgrades. > . what are those git tags which doomemacs keeps with the packages? > what does each such tag indicate, and how are these tags > maintained and updated? In the context of evolution of say ELPA, I am suggesting use of the model of streight.el. And its use based on the manifest model -- not doom's package adoption model. For each release of emacs, emacs{28,29,30} the archive will maintain a manifest-{28,29,30}. Each of those files enumerates a list of Git commit IDs for each of the packages in the archive. An update to the Git commit ID becomes a basis for a potential upgrade. > . what does it mean for a git tag to be "consistent"? It means that it is known to work well with all other Git commit IDs in that manifest. > . what are those "central manifests" you describe for Blee? what > does each manifest contain and how is it used? See manifest-{28,29,30} above. > . wrt your proposal of keeping separate manifests for each Emacs > release, how will a manifest for a specific release be updated, > and where will it be kept and made available for users? The manifests are an internal part of the archive. Users can see them, but they need not. Maintenance of a manifests is the work of the ELPA maintainers. They need to be subjected to regression tests/verification's that guarantee consistent sets. I think what I am saying above reflects current ad-doc practices of many straight.el users and reflects a natural evolution direction for package.el. Eli, if you have not used straight.el, I suggest experimenting with it. And again sorry about having been overly cryptic. ...Mohsen