From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "=?UTF-8?Q?Martin=20Edstr=C3=B6m?=" Newsgroups: gmane.emacs.devel Subject: Re: Reconsider defaults for use-package-vc-prefer-newest Date: Mon, 16 Sep 2024 18:46:48 +0200 (CEST) Message-ID: References: <86r09jddgk.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="34029"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "yandros" , "emacs-devel" To: "Eli Zaretskii" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 16 18:47:40 2024 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 1sqEt0-0008hZ-L6 for ged-emacs-devel@m.gmane-mx.org; Mon, 16 Sep 2024 18:47:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sqEsL-0002qt-Uk; Mon, 16 Sep 2024 12:46:57 -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 1sqEsK-0002qe-4L for emacs-devel@gnu.org; Mon, 16 Sep 2024 12:46:56 -0400 Original-Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sqEsH-0005o6-Np for emacs-devel@gnu.org; Mon, 16 Sep 2024 12:46:55 -0400 Original-Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit04.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1sqEsD-00EA9U-0t for emacs-devel@gnu.org; Mon, 16 Sep 2024 18:46:49 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.eu; s=selector1; h=Message-Id:In-Reply-To:References:Date:Subject:CC:To:From: MIME-Version:Content-Transfer-Encoding:Content-Type; bh=/uGpV2V6rmPK7WR4MuXEsyzLDVodomhd3xNUeW6Qz7Q=; b=GgK7A6p6ZGmO8CPCrw3/+q4mrk rSMtg5326G419m8P0sickzGNmFxkbBIbUDU7CvHAxvINo40Wqk9C9QpbDy5e5N9kyUsPdXcyu90+G D9bra/3MUvRNuxIPvFZcvQDqGX312n8F/Ga5s91xp4S+QEym14dg5BwUB4/7NaTmWDUUBPHjwrYF1 J0VXqfEwJuNvyn4EgPXrRLONBOkpAYm9jujpxAfvotEqQPzLsQkYCeQFenvFgRo9Ts6lfTbPF7xGs OQMqZY16dOaDxJ/QpOoqVoaDh+wNsV1col6rO17J4Jf+OCdWYjoI16tOQuI/VHGf+Jfb8PdM/XTTC UMVU+T+w==; Original-Received: from [10.9.9.129] (helo=rmmprod07.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1sqEsC-0007Zd-Gp; Mon, 16 Sep 2024 18:46:48 +0200 Original-Received: from mail by rmmprod07.runbox with local (Exim 4.86_2) (envelope-from ) id 1sqEsC-0007Da-FI; Mon, 16 Sep 2024 18:46:48 +0200 Content-Disposition: inline Original-Received: from [Authenticated alias (1196375)] by runbox.com with http (RMM6); Mon, 16 Sep 2024 16:46:48 GMT X-RMM-Aliasid: 1196375 X-Mailer: RMM6 In-Reply-To: <86r09jddgk.fsf@gnu.org> Received-SPF: pass client-ip=2a0c:5a00:149::25; envelope-from=meedstrom@runbox.eu; helo=mailtransmit04.runbox.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001 autolearn=unavailable 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:323669 Archived-At: On Mon, 16 Sep 2024 14:50:51 +0300, Eli Zaretskii wrote: =20 > If the problem is that there's a tag with the correct version, but the > Package-Version heading was not updated, we could perhaps have > use-package :vc detect that and either display a warning or even > automatically use the commit with the tag. Crucially, this is NOT the > latest commit in the Git repository, it is the commit which has the > latest release tag -- a far cry from what you suggested originally > (apologies if I misunderstood you back then.) I agree it's a good way forward if you are open to look up both the Package= -Version and the git tag and basically choose the highest-looking version b= etween the two. I had somehow ruled out that option. What I suggested was, technically, to get the latest commit *with a given P= ackage-Version*. Which need not be the same thing as the latest commit.=20 The latest commit could have a pre-release version like "0.6-pre", and so (= I assume...? Not sure) Emacs would walk back until finding the commit with = "0.6" and check out that one. It still looks necessary to me to do the change I suggested, since there ex= ists a population of developers who either believe that's how versions work= , or who do not really bump versions anyway. Since you can't educate everyo= ne, this is a situation for picking defaults that handle this reality. At worst, a package can have just ";; Package-Version: 0" since the very fi= rst commit, and no tag. I do not think that in this situation, the correct = move for use-package :vc is to install literally the first commit, when it = would be the very first package manager to behave in such a way.=20=20 It would be a deliberate introduction of breakage in the ecosystem, mainly = harming users. It does not matter if the packagers are not doing The Right = Thing, you gotta protect the users. Please consider what use-package :vc is for in the first place. It wouldn't= be used for things that exist on [Non]GNU ELPA, but for what exists off it= , so its behavior should not be modeled on what you can expect from package= s hosted there. On the contrary, its behavior can't expect any norms to be = followed. It's not necessarily incompetence nor disagreement about procedur= e; many novice developers also take their first baby steps in this wilderne= ss. Of course it is possible to use use-package :vc to install what's on the EL= PA, but the crowd that cares about running stable releases are going to be = the last ones to choose to do that. I can see an user switching to use-package :vc globally, but it'd be precis= ely because they want the bleeding edge version of everything, including th= e stuff on [Non]GNU ELPA. If they don't want it, they can simply elect not= do so for the stuff on [Non]GNU ELPA. > > - User installs Package using (use-package :vc) > > - User gets the version from 2021 > > - It doesn't seem to work > > - 10 such users give up on Package > > - The 11th user files the bug reports > > - Bug reports are strange and make no sense > > - User and Developer finally figure out that it's because the user used= (use-package :vc) which fetched the 2021 version >=20 > In any case, I wonder why the above mess you describe is not the fault > of the package developer, but of Emacs? It makes little sense to be, > TBH. I don't believe in blaming, but Emacs definitely has some of the responsibi= lity for the simple reason that this didn't use to happen and people do not= expect it to happen. A house of cards falls when someone shakes the table, but it isn't the faul= t of the one who put it together, it is who shook the table when they could= instead have permitted that artwork to stand. After knowing how this new Emacs builtin behaves, you can consider it to be= the fault of the developer who did not take it into account, at least if i= t is reasonable to expect all developers to be professionals that know how = every package manager works instead of only most of them, having missed thi= s one, but even then a crowd will resent this addition to their workload, a= s I have explained prior.=20 My own packaging experience would be unharmed if git tags become a valid ve= rsion identifier, but that just affects my packages. I'd like the ecosyste= m to have guarantees in place, and blaming devs because the fault is theirs= will not make them do The Right Thing. The right thing is that Emacs just= decline to shake the table. >=20 > > To counteract this would amount to a heuristic that looks up the packag= e repository online and compares the age of recent commits with the commit = fetched by (use-package :vc), but what is the threshold that you would set = to trigger the warning? I don't think it is realistically doable. >=20 > Why not? Detecting such suspicious "last versions" could be a good > idea and a good service to users, and is not that hard to implement. But how would you do it? All it takes is a single commit to introduce chang= es on which another package will rely. It can be as little as one minute b= etween the commits in question. Or conversely, a package may be mostly unc= hanged for years but that does not mean there is a problem. So that brings = us to a bunch of UX issues to answer. Should users "dismiss" each warning = individually? (Bear in mind there could be hundreds.) Should these dismis= sals be recorded in `custom-file` or some such location? It seems like a l= ot of effort to do well compared to my other suggestions, but that's just m= y impression.=