From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: Reconsider defaults for use-package-vc-prefer-newest Date: Wed, 25 Sep 2024 12:07:08 +0000 Message-ID: <87ikukrl77.fsf@posteo.net> References: <87wmj7dftf.fsf@posteo.net> <87setvxyt6.fsf@gmail.com> <87jzf7o13b.fsf@posteo.net> <87msk3jr0u.fsf@gmail.com> <87setum5do.fsf@posteo.net> <87msk1520e.fsf@gmail.com> <87settknf1.fsf@posteo.net> <87tte8akwa.fsf@gmail.com> <878qvjaep6.fsf@posteo.net> <87cykvwixn.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32434"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Martin =?utf-8?Q?Edstr=C3=B6m?= , "emacs-devel" , Tony Zorman To: Suhail Singh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 25 14:08:03 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 1stQoM-0008D1-Dj for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Sep 2024 14:08:02 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1stQnm-0002ww-Il; Wed, 25 Sep 2024 08:07:27 -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 1stQnd-0002hM-6r for emacs-devel@gnu.org; Wed, 25 Sep 2024 08:07:17 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1stQna-0002DO-Fs for emacs-devel@gnu.org; Wed, 25 Sep 2024 08:07:16 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 9B1C7240101 for ; Wed, 25 Sep 2024 14:07:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1727266029; bh=cTdy9LVa6yy0pNHAk82z6SRffTasBuNlRmIwV0yVL5g=; h=From:To:Cc:Subject:Autocrypt:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=eE2SxwCSebZoAsKTilRU5B5KMo4ZH9cpPafqghJB0hn6yYKdG1zgskV2qBvLXM/AX F1LZvcTfi79lz05anP7MHYBlTolndGblMy7DAh9D3jYCda0ZCtaoJRRhxdYQGso0p9 dba4YrmLW2vc+UoPAKVF7jYLCpgxoywo9UfUNCMK54nqC6KURLZVLdWHe6PsqAMWP1 0oqNWXFX/luP9vAs9vP+gX7xA5ok4htBHQ+GHNCkw9pEh/Ln2krjHxX9CBtRZfVucl SejiKGS7AiioBhubF+NT/AKWe+EFcbUtHDQ+Wh/rfI6Xh5lHhiDp5on75puySQRVkP 0+tFe+fMMROlg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4XDFpN36hkz6tm4; Wed, 25 Sep 2024 14:07:08 +0200 (CEST) In-Reply-To: <87cykvwixn.fsf@gmail.com> (Suhail Singh's message of "Sun, 22 Sep 2024 16:08:04 -0400") Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM OpenPGP: id=philipk@posteo.net; url="https://keys.openpgp.org/vks/v1/by-email/philipk@posteo.net"; preference=signencrypt Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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:324063 Archived-At: --=-=-= Content-Type: text/plain Suhail Singh writes: > Philip Kaludercic writes: > >>>> In your case/the case of julia-mode, something like >>>> >>>> Other versions: 1.2.3 (melpa-stable, COMMIT MISMATCH). >>>> >>>> with a help annotation. >>> >>> Yes, something like that would have worked. Thanks in advance, if you >>> do implement something of that nature. It would be useful. >> >> Can you test if this works: > > The patch you shared does /something/, but it's not clear to me what the > expected behaviour is supposed to be. Could you please comment? The idea is to add a "COMMIT MISMATCH" warning whenever we detect that two packages have different commits. What this doesn't do yet is eliminate false positives, such as different commits between a local version of a package and a remote version. I guess we are only interested in differences between remote packages, right? > Specifically, in the case of casual-dired (latest available on > melpa-stable is 1.8.2 and I have 1.8.1 installed), I observe the > following when viewing the package description: > > #+begin_quote > Other versions: 1.8.1 (installed, COMMIT MISMATCH!), 20240917.401 (melpa). > #+end_quote Does MELPA annotate their packages with commits? > > The commit that introduced the 1.8.1 version header isn't the same as > the one that was assigned the git tag, so the above makes sense. > The fact that the melpa version doesn't have a corresponding COMMIT > MISMATCH seems desirable (since there's no expectation for the melpa > version to correspond to the package header in any way). There is no causal-dired package on ELPA, so version headers don't matter here since MELPA-stable relies on Git tags. > However, when I view the package description for casual-suite (the > latest on melpa-stable is 1.6.0 and I have the same installed), I > observe: > > #+begin_quote > Other versions: 1.6.0 (melpa-stable). > #+end_quote > > > Given that the commit that introduced the 1.6.0 version in the package > header is different from the one that was tagged by the git tag, I would > have expected a COMMIT MISMATCH in the above as well. The absence of it > seems like a bug. As mentioned above, this is to be expected. MELPA ignores the Version header, and given just the tarball, we cannot detect the discrepancy you mention. > The situation gets weirder when I observe the description of htmlize. > > From the melpa archive: > > #+begin_quote > Other versions: 20240915.1657 (installed), 1.58 (nongnu, COMMIT MISMATCH!), 1.58 (melpa-stable, COMMIT MISMATCH!). > #+end_quote > > > From the melpa-stable archive: > > #+begin_quote > Other versions: 20240915.1657 (installed, COMMIT MISMATCH!), 1.58 (nongnu), 20240915.1657 (melpa, COMMIT MISMATCH!). > #+end_quote > > > From the nongnu archive: > > #+begin_quote > Other versions: 20240915.1657 (installed, COMMIT MISMATCH!), 1.58 (melpa-stable), 20240915.1657 (melpa, COMMIT MISMATCH!). > #+end_quote > > Could you comment on what's happening above? The fist one is fine, because you have installed the MELPA unstable package, which appears to be ahead of both the MELPA and the NonGNU version. The last two though appear to be in sync, so the commit that bumped the version tag is also the one that was tagged for release. That is why in the last two, you see that there is no MISMATCH between nongnu and melpa-stable (and vice-versa). As mentioned in my previous message, I think it might be less confusing if we just focus on mismatches between remote packages? Does this change improve that? --=-=-= Content-Type: text/plain Content-Disposition: inline diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el index 7cae8d68bc0..1c7c2f40aa7 100644 --- a/lisp/emacs-lisp/package.el +++ b/lisp/emacs-lisp/package.el @@ -2961,23 +2961,28 @@ describe-package-1 (cdr (assq name package-archive-contents)) (let ((bi (assq name package--builtins))) (if bi (list (package--from-builtin bi)))))) - (other-pkgs (delete desc all-pkgs))) + (other-pkgs (delete desc all-pkgs)) + (commit (alist-get :commit (package-desc-extras desc)))) (when other-pkgs (package--print-help-section "Other versions" (mapconcat (lambda (opkg) (let* ((ov (package-desc-version opkg)) (dir (package-desc-dir opkg)) (from (or (package-desc-archive opkg) - (if (stringp dir) "installed" dir)))) + (if (stringp dir) "installed" dir))) + (ocommit (alist-get :commit (package-desc-extras opkg)))) (if (not ov) (format "%s" from) - (format "%s (%s)" + (format "%s (%s%s)" (make-text-button (package-version-join ov) nil 'font-lock-face 'link 'follow-link t 'action (lambda (_button) (describe-package opkg))) - from)))) + from + (if (and (not (package-desc-dir opkg)) + (equal ocommit commit)) + "" ", COMMIT MISMATCH!"))))) other-pkgs ", ") "."))) --=-=-= Content-Type: text/plain >>> That being said, however, based on a recent exchange, the recommended >>> version that the maintainer of julia-mode wishes users download is the >>> "rolling release" equivalent from melpa. I believe it is for this >>> reason that they have not made a tagged release in the last four years. >>> Quoting below the maintainer's response on the issue ([1]) where I >>> brought this matter to their attention: >>> >>> #+begin_quote >>> Since we do not make stable releases (effectively, it is just rolling on >>> `master`, I think we should just clarify that users should use `melpa`, and if >>> possible expunge the package from `melpa-stable` etc. >>> #+end_quote >>> >>> [1]: >> >> If that is so, then we can also mark the ELPA package as using a >> rolling-release model, i.e. the build server prepares a new tarball >> every time is synchronises new commits. > > I believe that that would be desirable, and the accurate thing in the > case of julia-mode. Could you please confirm when that change has been > made. I haven't changed anything. Are you involved in julia-mode? > Additionally, could you please point me to where the "rolling-release > model" is documented? A search for "rolling" in > didn't > yield any matches. It is documented on the elpa-admin branch: https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/README?h=elpa-admin&id=9bd65395f1d4875915731ddbdd73a471f10d7794#n215 That being said, I still think that this is a feature that we would want to advise package maintainers not to use. -- Philip Kaludercic on siskin --=-=-=--