From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii 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 19:19:16 +0300 Message-ID: <83mt3588or.fsf@gnu.org> 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: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36792"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dmitry@gutov.dev, emacs-devel@gnu.org To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 18 18:20: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 1poo3n-0009Ni-ON for ged-emacs-devel@m.gmane-mx.org; Tue, 18 Apr 2023 18:20:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1poo2w-0005Ps-1Y; Tue, 18 Apr 2023 12:19:10 -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 1poo2u-0005Pg-Dh for emacs-devel@gnu.org; Tue, 18 Apr 2023 12:19:08 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1poo2t-0000T5-TJ; Tue, 18 Apr 2023 12:19:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=McHhjQ4x6s+5+xM8rkdU1h3hN1c/6MM2GBbRAxnYI7g=; b=Xlhq4zkHwS0JRdDxFdrU 4jw+GVqYm3Gx1lhoweYa4i8JWepnFeNBkJPbJkaxMqxc0JI67zfrK+7hAm6Q8tjcpWPJQePZKeKgl dmAdSrmhzfkxkDvvKwSDAtLSVjIv904eDg6xQT9qOj2pdvs+D4HPR65LuRpUTDKpKzE9vCq1e3Wvq xBprSzk3cXggGM63wwm8okPPWTPepkPWNsEVRsfEB5kYi7D78H2WCubUr2jFyk6eZga03c0Ci/Vx8 qe3ercWICGyRWfpfycGnh9dqChSq9b32ePLSik2lV5CwIzDLXWUlKkyNBinau3ybR8C40n1FjbHj+ afjWHeNSbH4tfQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1poo2t-00044Q-5q; Tue, 18 Apr 2023 12:19:07 -0400 In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Tue, 18 Apr 2023 16:45:33 +0100) 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:305414 Archived-At: > From: João Távora > Date: Tue, 18 Apr 2023 16:45:33 +0100 > Cc: dmitry@gutov.dev, emacs-devel@gnu.org > > > > 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. It isn't like ElDoc is not available in Emacs 29. > 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. My point is that Eglot and any other core package will do its users a favor if it deliberately and consistently makes a point to depend on as few _new_ features of other core packages as possible. If you disagree with that, then we will have to agree to disagree, because for me this is a very basic issue with core packages and the future of Emacs. > 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. Which IMO is not a good thing, not unless Eglot 1.14 has fallbacks for when these features are not available. But if that is impossible or impractical for some reason in this particular case, then it simply means that users of Emacs 29 will be unable to upgrade Eglot without also risking less stability due to upgrading the dependencies. Again, if you don't think this "dependencies hell" is a Bad Thing in general, we will have to agree to disagree. > 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. I consider each case of a request to backport on its own merit. So conclusions such as the above, which don't consider the specifics of each change, but instead go by some abstract principles, are not what I usually make. > > 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. You are missing my point. I'm not talking about dependencies with other packages. My point is not about other core packages, it's about Emacs itself and its stability as a whole. Users of a stable release of Emacs can, and usually do, expect their entire Emacs configurations to be stable, and telling them to upgrade packages without any clear indication of their stability goes against that. Yes, requiring specific versions of the other N packages will minimize breakage due to incompatibilities between those packages, but what about unintended consequences, regressions, etc.? Suppose Eglot 1.14 brings with it some package whose updated version has a bug -- why should a user who wants to have a stable Emacs environment to risk this? > > 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. I'm asking whether you make an extra effort to avoid such requirements whenever possible, even if that would call for extra work on your part? I hope you and other package developers do, because otherwise proliferation of core packages would be a very bad deal for the future of Emacs, which traditionally is perceived as an extremely stable platform. > > 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. If you at least think we should try, then we have something to work with. Even if the ideal of having to upgrade no package is unattainable, bringing the number close to zero is a worthy goal. > 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. I'm saying that we should make an extra effort to avoid that, not accept dependencies without a "fight". > 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 not sure history is the aspect that distinguishes them. An important aspect is how "low' is the functionality provided by the package. Some packages provide infrastructure -- those affect many other places by definition. Others are applications on which nothing else depends. Perhaps these are the important factors, I don't know. > - 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. That is completely irrelevant for this discussion, IMO. It is up to the users whether to upgrade and how aggressively. We don't know enough about the configurations, the environment, and the usage patterns of the users, we can only give them information -- in this case regarding stability of each available version -- and let them make the conclusions as they see fit. We will never be able to second guess them well enough.