From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Corwin Brust Newsgroups: gmane.emacs.devel Subject: Re: Stability of core packages Date: Sun, 30 Apr 2023 08:12:57 -0500 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="9599"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Mohsen BANAN Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 30 15:13:48 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 1pt6s8-0002MM-NS for ged-emacs-devel@m.gmane-mx.org; Sun, 30 Apr 2023 15:13:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pt6rb-0007Qs-LQ; Sun, 30 Apr 2023 09:13:15 -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 1pt6rX-0007Qe-RX for emacs-devel@gnu.org; Sun, 30 Apr 2023 09:13:12 -0400 Original-Received: from mail-oi1-f169.google.com ([209.85.167.169]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pt6rV-0005PZ-Ta; Sun, 30 Apr 2023 09:13:11 -0400 Original-Received: by mail-oi1-f169.google.com with SMTP id 5614622812f47-38e7ce73ca0so1065609b6e.2; Sun, 30 Apr 2023 06:13:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682860388; x=1685452388; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hDNhmQcSEDDr4R72EkYptBCqXydM9b5kp9VGbHICyfE=; b=JJubE9/wpqEGdi3Aq47ylIHMvcg5ZAOVmL9I6os3DqInQZdMfbkPKOZyNuwQuNqmQQ VPn/p5guFnoys+aQ5uxWil/KqtMIC0rjI2hAMykld0JY+1vRotEqLvy9EUszP0hzKsuY i1Rzc0fHbGlLFh62GtzfO6m+EuWf4UvDNYCxKeMxfxDLvoquoPe6OMDsnSf6ptk9FSrp KpIZRMRXm54lPA4G8ay7IynwYRIZ6nEd2llY+3joU//x9L82strELX+VCUo7LaQwbsbq 2eoc7jNsc6DDAPbY1B/V8UHiN8sif0rMPwCnU5HxXuFJBfNnttAl3j76coO7OuIKHjDA 9QOQ== X-Gm-Message-State: AC+VfDzz6mWKHqDErsM1s8s5Qd8zh7XlH/p5AWfKJ58Z76a/XUbNM62p osh/oC3MZpd/NpMOrH4dpyCneW+0YiYdoCHDtf0= X-Google-Smtp-Source: ACHHUZ57BP6F5t8MJDZacgguyZU4nbVcWiON8B80+R2HF+Hr5iCWEVpDGlzRZ/ftDrwkPlk0UfPRsuuC/YLh3n5Emh8= X-Received: by 2002:a05:6808:13d4:b0:392:2c28:ca46 with SMTP id d20-20020a05680813d400b003922c28ca46mr119168oiw.10.1682860388199; Sun, 30 Apr 2023 06:13:08 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=209.85.167.169; envelope-from=mplscorwin@gmail.com; helo=mail-oi1-f169.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action 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:305734 Archived-At: On Sat, Apr 29, 2023 at 4:47=E2=80=AFPM Mohsen BANAN wrote: > > >> 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. [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. I don't see anything like this level of practice maturity from doom (or straight), 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. 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. [1] https://github.com/doomemacs/doomemacs/branches