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, 06 May 2023 22:58:38 -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="26253"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1.50 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org, =?utf-8?B?Sm8=?= =?utf-8?B?w6NvIFTDoXZvcmE=?= To: Corwin Brust Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 07 08:53:40 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 1pvYH6-0006jR-7a for ged-emacs-devel@m.gmane-mx.org; Sun, 07 May 2023 08:53:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pvYGU-0004gg-VN; Sun, 07 May 2023 02:53:02 -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 1pvXPz-00033C-O4 for emacs-devel@gnu.org; Sun, 07 May 2023 01:58:47 -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 1pvXPx-00036Y-Nv for emacs-devel@gnu.org; Sun, 07 May 2023 01:58:47 -0400 Original-Received: (qmail 32492 invoked from network); 7 May 2023 05:58:40 -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; 07 May 2023 05:58:40 -0000 In-Reply-To: (Corwin Brust's message of "Sun, 30 Apr 2023 08:12:57 -0500") 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: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 07 May 2023 02:52:58 -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:305941 Archived-At: Corwin Brust writes: > On Sat, Apr 29, 2023 at 4:47=E2=80=AFPM Mohsen BANAN > wrote: >> ... >> >> If you want to go with something like this, you >> >> have to revisit the package retrieval model. > > [SNIP] > >> ----------- >> 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: > This is the same doomemacs project[1] that does all development > against HEAD of master, correct? I track three Emacs branches, all > of which see frequent pushes. Work is regularly merged back to trunk. My mentioning doomemacs was not an endorsement of doomemacs ... > so I think the lesson here isn't technical, but > something more like: > > 1. For powerusers, package.el isn't better than manually tracking > package versions. > 2. Tracking package versions is so difficult that Emacs > re-distributers find it worthwhile to hard-code working combinations. > > I think the issue is the packaging landscape has matured significantly > thus it is time to reconsider the uses-cases Emacs should support - > and that's the point of this thread. Exactly. > Meanwhile, I think the practical upshot of the approach taken by doom > (and straight.el, in general) is to push tracking what versions of > which packages work together to individual uses. I feel it would be a > step backward for Emacs to adopt this approach as the default, > expecting all users to learn to do it. User-managed explicit package > version pinning does seem like a cool thing to support -- I hope > package-vc helps pave the way for core support for that use-case. But > it should not be the default: I would be sad if we decide to expect > new users to master package pinning to try out new features. That is not what I am saying or suggesting. Over the past several years, we have learned various things from: 1) the packaging landscape 2) package archive providers 3) Emacs re-distributers Right now, in practice, Emacs re-distributers maintain the stable manifest of the matching sets for each release of emacs. I am suggesting two things: 1) package.el should evolve or be replaced with something that is the equivalent of straight.el. 2) The responsibility for maintaining a stable matching set of packages for each release of emacs should come down to package archive providers (not the Emacs re-distributers). Package archive providers should maintain stable and consistent manifests. Emacs re-distributers and emacs end-users can selectively overwrite these, but that won't be the default. The challenge here is that in the existing emacs ecosystem, basic emacs (emacs+elpa), package archive providers and emacs re-distributers have no structure to facilitate convergence. If basic emacs (emacs+elpa) could solve this properly, the rest could have a pattern to emulate. For that to happen, basic emacs needs to learn the lessons of emacs re-distributers. That was why I mentioned that experimenting with straight.el is a good idea. Not as a capability, but as a basis for existing policies and practices. ...Mohsen