Re: Reconsider defaults for use-package-vc-prefer-newest

[Philip Kaludercic <philipk@posteo.net>]

[-- Attachment #1: Type: text/plain, Size: 3569 bytes --]

Suhail Singh <suhailsingh247@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> 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?


[-- Attachment #2: Type: text/plain, Size: 2115 bytes --]

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 ", ")
           ".")))
 

[-- Attachment #3: Type: text/plain, Size: 1714 bytes --]


>>> 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]: <https://github.com/JuliaEditorSupport/julia-emacs/issues/212#issuecomment-2328150198>
>>
>> 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
> <https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README> 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