From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot) Date: Tue, 18 Apr 2023 16:45:33 +0100 Message-ID: References: <87a5zj2vfo.fsf@gmail.com> <83wn2h5825.fsf@gnu.org> <87wn2gkhzr.fsf@posteo.net> <83cz485oxi.fsf@gnu.org> <87leiwdyff.fsf@posteo.net> <834jpk5hih.fsf@gnu.org> <871qkom3fj.fsf@posteo.net> <83mt3b4yfc.fsf@gnu.org> <87edonlsxi.fsf@posteo.net> <83jzyf4vzb.fsf@gnu.org> <871qknllkj.fsf@posteo.net> <83fs934pjf.fsf@gnu.org> <87wn2fk47y.fsf@posteo.net> <83sfd2g2ek.fsf@gnu.org> <875y9yfxrr.fsf@gmail.com> <87y1muefks.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> <83pm818cx2.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="18967"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dmitry@gutov.dev, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 18 17:46: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 1ponXT-0004e1-EW for ged-emacs-devel@m.gmane-mx.org; Tue, 18 Apr 2023 17:46:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ponWh-0000Yj-7D; Tue, 18 Apr 2023 11:45:51 -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 1ponWe-0000YZ-IW for emacs-devel@gnu.org; Tue, 18 Apr 2023 11:45:48 -0400 Original-Received: from mail-ot1-x336.google.com ([2607:f8b0:4864:20::336]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ponWc-0002S9-Go; Tue, 18 Apr 2023 11:45:48 -0400 Original-Received: by mail-ot1-x336.google.com with SMTP id 46e09a7af769-6a5f765d595so507223a34.0; Tue, 18 Apr 2023 08:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681832744; x=1684424744; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KOKcSs1zFWt7gsdzLgDErfudTCMmdvUddYlcAr74Lys=; b=qwbiCRi8C8A/EI9wFsbLgNtUir4v5eCm2J0j0I32bEOsl2me0vGlItnMonuJFT72yy ERbzFT3Ai2lcWqHlKZtWGArO/ZT8ptKijrh2AiBnDUOXZc2vbTPP8hlCT0mnHEGphc6n spJAvDM8RFKDWLw53TpjsjNAiuh55yDLCSMx/PTSMNGF1baZGMvZLK6lJDxOIO3hbI8u Vx182TegiNZFdiQEsXPjQh5VDsmVL6PqtZInSxkyIVHM/VAT7569lofwwanpCqsR9ZW+ D4fUseRumKgQKmWYIRkLHTWtEVsMEw8ov+uP9qtS9VxnEDhxxjl7vQOOhNDi1/vEoJm9 fNcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681832744; x=1684424744; 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=KOKcSs1zFWt7gsdzLgDErfudTCMmdvUddYlcAr74Lys=; b=LmJrfVRiAjUIz8YEgZ+r2rZ7Ob9y7iRXjw3XUU6ksZm4qOGl3yHwQtOG1+4UGxkfUK ntY7rlfJPd05Obs4sPa0nEN0C+GbrG/RYPRtpW6qfMUDmtgSCLAcUvjwsKMgl0P77evu wzJQeb1y3DMJZcdVODm07O4ZYevgWmwpCA63OmPu08LQXEU0YBqZQoFFwcWA8oJJiC4K h9V0FZQA3rjqDB2J4PzmNhO0kyKxxRquL7YSbq9AxkhFWAp/k0p7yiwSBgTduP9gsJzA 5ZHnPEbaHE7IlP/VrMicPdSwFBkPZcbPimXXzByByabskRx52js/6dJz4ZDhvA6l8Apc QHzg== X-Gm-Message-State: AAQBX9fXGOmWI2T272sFGW+HMGu5XrppuDy/ViJ18JbjwdzTtUE3mFy4 KGy89+11nfKBS/MrpzDdYaDBZ5R23W8fgfu3E4Lo1Y58/3k= X-Google-Smtp-Source: AKy350Z6Jw/0mmxcBWJQLfLUXzX1vkleuPJmic8YpuWLeEa5Dz0kFwlSql800TgU0hfNzeqm5CSB2eHK497geWNH48o= X-Received: by 2002:a9d:5e8e:0:b0:6a5:ea63:b9f3 with SMTP id f14-20020a9d5e8e000000b006a5ea63b9f3mr820156otl.4.1681832744481; Tue, 18 Apr 2023 08:45:44 -0700 (PDT) In-Reply-To: <83pm818cx2.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::336; envelope-from=joaotavora@gmail.com; helo=mail-ot1-x336.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham 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:305413 Archived-At: On Tue, Apr 18, 2023 at 3:47=E2=80=AFPM Eli Zaretskii wrote: > > > From: Jo=C3=A3o T=C3=A1vora > > Date: Tue, 18 Apr 2023 15:02:01 +0100 > > Cc: Dmitry Gutov , emacs-devel@gnu.org > > > > On Tue, Apr 18, 2023 at 1:56=E2=80=AFPM Eli Zaretskii wr= ote: > > > > > without by side effect installing a newer and potentially less stable > > > ElDoc. (I also am surprised that change is a must for Eglot 1.15.) > > > > It's not a "must". Eglot can work without it. The problem happens in > > ElDoc and doesn't affect its interface. > > Then what Dmitry said about Eglot 1.15 being dependent on that change > in ElDoc is not relevant to the issue at hand, which is whether Eglot > 1.15 could be bundled with Emacs 29.1. It is quite relevant. Eglot 1.15 depends on many other things in ElDoc. That particular bugfix might not -- or might indeed -- included, depending on what other non-bugfix things Eglot will require of ElDoc at the time. ElDoc is now 1.14 but it could be 1.15 at the time motivated by Eglot 1.15/16/17. And even in ElDoc 1.14 there are already things (the :echo display option) that are not in Emacs 29. And Eglot 1.14 directly depends on those things. It relies on them to do a good job. I would think that if you oppose a bugfix backport you would also oppose a _feature_ backport, which usually is (and is indeed in this case) a much more complicated, "scary", bug-prone development. > > But Eglot relies on ElDoc as a whole. In general you can't expect > > to have new features in Eglot without some advancing of the > > infrastructure that Eglot depends on. > > Understood. My point is that if you want Eglot users to be able to > upgrade to a newer versions, you need to have compatibility layers, to > avoid the need to upgrade too many other packages, which might hamper > stability. Otherwise, we cannot in good faith recommend that users of > stable Emacs update their core packages without a second thought. Yes, and this is why each released version of Eglot specifies exactly the _released_ versions of its dependencies that it depends on. The dependency language isn't very elaborated (there is no way to say Eglot 1.1234 depends on ElDoc between 1.23 and 1.56), but it's been enough. It's not much different from what is found in numerous other package systems. Another matter is what package.el does with this info and the implied graph. Transitive dependencies are known not to matter. And if a package requires ElDoc 1.14 but 1.99 is already available package.el will just go ahead and install the latest. Always has, I'm afraid (anyone can correct me on this if I'm mistaken, which I'd love to be). I think the experience of the straight.el and elpaca.el package manager authors could be useful here to us. If someone knows them by heart, please do tell me. Who knows, maybe what we want is to bring one of these into Emacs and kill package.el. straight.el is what a lot of people seem to be using these days anyway (and the cooler kids elpaca.el). > > So there _isn't_ a way to partially upgrade a package and not its > > dependencies. > > Updating a package P1 should require update of as few packages P2...Pn > as possible. Ideally, none at all. And very often that does happen, I suppose. Not every Eglot release _requires_ installation of new versions of its dependencies. But some do. > Users should be able to decide > whether they want or don't want to update any single package without > also needing to decide whether they are okay with updating half a > dozen of others. This should be our goal, because otherwise updating > a package will be unsafe if you use any Emacs except master (and thus > don't care much about stability anyway). I don't know how you can meet that goal in general. We should indeed work to minimize dependencies and do things that don't affect interfaces and don't require changes other's interfaces. As much as possible, I agree. But in general programs rely on other programs. Dependencies exist. Like in many other package managers, users should be presented with the consequences of their wishes, when that is feasible and when we can do so without breaking their configs. That's my idea of stability anyways. > > "there shouldn't be a single set of criteria governing core > > packages". Then we can teach Emacs's upgrade mechanisms to > > deal with each set differently, carefully examining the > > requirements for each set. > > Sure, but we need to have these sets, actually. Right now, we don't, > not for every core package out there anyway. [ Just a note that :core packages are not "out there", they're "in here" -- by definition. That's their main selling point and precisely what we should take advantage of :-) ] I propose two main sets of :core packages to start with. Set 1 - :core packages that have always been core, i.e. they started their life in the code Set 2 - :core packages that started their life somewhere else (GNU ELPA, Github, etc), were installable through ELPA interfaces and now are :core (which means Git-versioned in Emacs.git but still installable via ELPA). Two known such packages are Eglot and Use-Package. Both depend on _other_ :core packages. Eglot on many of these, Use-Package only on "bind-key", which is also new, but didn't seem to be installable independently before Use-Package appeared. This isn't the end of the analysis, of course. I'm just providing these two sets to see if it rings a bell with participants, because from the opinions I collected in that very long bug, they seem to make and map neatly onto the requirements that each party put forth: - That members of set 1 shouldn't be upgradable "willy nilly" to maintain exact backward-compatibility. - That members of set 2 should be upgraded in much easier fashion because that's what guarantees that people's configs already doing so won't break. > > I'd like you, if possible, to also respond (here, if you prefer) to the > > points I raised in my own reply to Dmitry's message you're replying > > to. This is the message;: > > > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D62720#529 > > I didn't respond because I had nothing to say to that which I didn't > already say in response to Dmitry's message. I proposed a simple bugfix to bug#62720, based precisely on the above idea of separation of sets. A dead-simple 7-line fix. That patch was +1'ed by Philip and Dmitry and hasn't been addressed by you. Philip, by the way, tried until the end to give you a patch that also didn't have the non-interactive package-install/use-package lockout, but you insisted. Why? Why keep it for those members of Set 1? What is there to be gained? Do you acknowledge what there is to be lost? But moving on from that minor tragedy, it's nevertheless easy to note that bug#62720 conflates the two sets. We should work to improve that, hopefully in time to avert damage. The code required to express these sets in Elisp is, of course, quite trivial. Jo=C3=A3o