bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

[J.P.]

0. HOME=$(mktemp -d) ./src/emacs --no-site-file
1. (require 'package)
2. (push '("devel" . "https://elpa.gnu.org/devel/") package-archives)
3. M-x list-packages RET
4. Wait for "Package refresh done"
5. Find _erc_ 5.6snapshot0.2024... available devel ...
6. Hit the _erc_ button:

   => describe-package-1: Wrong type argument: char-or-string-p,
      ("Amin Bandali" . "bandali@gnu.org")

7. As a workaround, with point still on _erc_, M-:

   (let ((desc (get-text-property (point) 'package-desc)))
     (cl-callf car (alist-get :maintainer (package-desc-extras desc))))

   RET RET

Perhaps I'm hallucinating, but for some reason I was under the
impression the ELPA production instance combined multiple maintainers
into a single conjoined entity. At least I seem to remember something
like that being in effect back when ERC first encountered this in
setting up its own CI endpoint [1]. In any case, it'd be nice to somehow
fix this if it's looking like ERC 5.6 will be affected once it's
released. Please let me know if anything's required on our end.

Thanks.
J.P.


[1] https://emacs-erc.gitlab.io/bugs/archive/

    (like 2+ yrs ago) which resulted in a poor man's hack:

    https://gitlab.com/emacs-erc/bugs/-/raw/master/resources/elpa/combine-maints.el


In GNU Emacs 29.2.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.17.6) of 2024-01-22 built on localhost
Repository revision: 51ca049608cd116e5ec5b8bb4fd815bed1cbf4ca
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 37 (Workstation Edition)

Configured using:
 'configure --enable-check-lisp-object-type --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3'
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util text-property-search time-date mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils erc-autoloads info
compat-autoloads package browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie generate-lisp-file url-domsuf
url-util mailcap url-handlers url-parse auth-source cl-seq eieio
eieio-core cl-macs password-cache json subr-x map byte-opt gv bytecomp
byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
emacs)

Memory information:
((conses 16 61064 6695)
 (symbols 48 7538 0)
 (strings 32 22236 1944)
 (string-bytes 1 654864)
 (vectors 16 15788)
 (vector-slots 8 213878 7973)
 (floats 8 27 32)
 (intervals 56 243 0)
 (buffers 976 10))

bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> 0. HOME=$(mktemp -d) ./src/emacs --no-site-file
> 1. (require 'package)
> 2. (push '("devel" . "https://elpa.gnu.org/devel/") package-archives)
> 3. M-x list-packages RET
> 4. Wait for "Package refresh done"
> 5. Find _erc_ 5.6snapshot0.2024... available devel ...
> 6. Hit the _erc_ button:
>
>    => describe-package-1: Wrong type argument: char-or-string-p,
>       ("Amin Bandali" . "bandali@gnu.org")

I believe this is already fixed in `master`.
Luckily, this bug does not affect `package-install`.


        Stefan

bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

[J.P.]

Hi Stefan,

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 6. Hit the _erc_ button:
>>
>>    => describe-package-1: Wrong type argument: char-or-string-p,
>>       ("Amin Bandali" . "bandali@gnu.org")
>
> I believe this is already fixed in `master`.
> Luckily, this bug does not affect `package-install`.

Hm, I'm starting to suspect this perceived "breakage" may in fact be
intentional (i.e., a "schema evolution"), at least on the /devel
endpoint, given it seems to be reflected in the disparity between

  ;; /devel/archive-contents
  (:maintainer ("Bob Weiner" . "rsw@gnu.org")
               ("Mats Lidell" . "matsl@gnu.org"))

and

  ;; /packages/archive-contents
  (:maintainer "Bob Weiner <rsw@gnu.org>, Mats Lidell"
               . "matsl@gnu.org")

And likewise for ./foo-pkg.el in

  ;; /devel/foo-42.0.tar
  (define-package ... :maintainer
    '(("Bob Weiner" . "rsw@gnu.org") ("Mats Lidell" . "matsl@gnu.org")))

vs.

  ;; /packages/foo-42.0.tar
  (define-package ... :maintainer
    '("Bob Weiner <rsw@gnu.org>, Mats Lidell" . "matsl@gnu.org"))

Assuming this isn't a red herring, will this perceived dichotomy hold
going forward? That is, can we count on releases at the /packages
endpoint being of the improper-list variety and not the alist variety
for the foreseeable future? If so, then I guess this bug is much ado
about nothing and can be closed, since ERC 5.6+ will be installable on
27+ in the manner recommended in our docs.

Thanks,
J.P.

bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Hm, I'm starting to suspect this perceived "breakage" may in fact be
> intentional (i.e., a "schema evolution"), at least on the /devel
> endpoint, given it seems to be reflected in the disparity between
>
>   ;; /devel/archive-contents
>   (:maintainer ("Bob Weiner" . "rsw@gnu.org")
>                ("Mats Lidell" . "matsl@gnu.org"))
>
> and
>
>   ;; /packages/archive-contents
>   (:maintainer "Bob Weiner <rsw@gnu.org>, Mats Lidell"
>                . "matsl@gnu.org")

That just depends on when the package was built (i.e. before or after
`elpa.gnu.org`s Emacs was upgraded from Emacs-27 to Emacs-28).

> And likewise for ./foo-pkg.el in
>
>   ;; /devel/foo-42.0.tar
>   (define-package ... :maintainer
>     '(("Bob Weiner" . "rsw@gnu.org") ("Mats Lidell" . "matsl@gnu.org")))
>
> vs.
>
>   ;; /packages/foo-42.0.tar
>   (define-package ... :maintainer
>     '("Bob Weiner <rsw@gnu.org>, Mats Lidell" . "matsl@gnu.org"))

Same thing.

> Assuming this isn't a red herring, will this perceived dichotomy hold
> going forward? That is, can we count on releases at the /packages
> endpoint being of the improper-list variety and not the alist variety
> for the foreseeable future?

No.

> If so, then I guess this bug is much ado about nothing and can be
> closed, since ERC 5.6+ will be installable on 27+ in the manner
> recommended in our docs.

Its installable via `package-install`, but not from the
`package-menu-describe-package` because of this bug in that command.


        Stefan

bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

[J.P.]

Hi Stefan,

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Hm, I'm starting to suspect this perceived "breakage" may in fact be
>> intentional (i.e., a "schema evolution"), at least on the /devel
>> endpoint, given it seems to be reflected in the disparity between
>>
>>   ;; /devel/archive-contents
>>   (:maintainer ("Bob Weiner" . "rsw@gnu.org")
>>                ("Mats Lidell" . "matsl@gnu.org"))
>>
>> and
>>
>>   ;; /packages/archive-contents
>>   (:maintainer "Bob Weiner <rsw@gnu.org>, Mats Lidell"
>>                . "matsl@gnu.org")
>
> That just depends on when the package was built (i.e. before or after
> `elpa.gnu.org`s Emacs was upgraded from Emacs-27 to Emacs-28).

Not sure if this is relevant, but it seems `package-archive-version' is
1 on both sides of this divide. Should it maybe have been incremented?

[...]
>
>> Assuming this isn't a red herring, will this perceived dichotomy hold
>> going forward? That is, can we count on releases at the /packages
>> endpoint being of the improper-list variety and not the alist variety
>> for the foreseeable future?
>
> No.

Perhaps GNU ELPA would consider versioned endpoints serving the same
resources in older formats, e.g.,

  /package/v1
  /devel/v1

>> If so, then I guess this bug is much ado about nothing and can be
>> closed, since ERC 5.6+ will be installable on 27+ in the manner
>> recommended in our docs.
>
> Its installable via `package-install`, but not from the
> `package-menu-describe-package` because of this bug in that command.

This indeed works interactively on Emacs 29. Thanks.

However, ERC also supports versions 27 and 28. What's the recommended
way for folks to upgrade on those Emacsen? The least gruesome thing I
could conjure up is

  (package-install (car (alist-get 'erc package-archive-contents)))

But that's still a rather unfriendly incantation, IMO.

Also, pardon my ignorance here, but it was my understanding that M-x
list-packages RET is meant to be the de facto entry point for baseline
upgrade functionality in Emacs.

If you'll recall, during the lead up to Emacs 29's release, various
discussions unfolded in and around

  bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot

And throughout these, the following method held firm as a surefire way
for upgrading a :core package:

  "It's not impossible to upgrade in Emacs 29, of course. The only way I
  know is to M-x package-list-packages, find Eglot 1.14 in the list,
  mark it with 'i' and confirm installation with 'x'. But it is very
  awkward." [1]

Despite being "awkward," this method was acknowledged as reliable by
multiple parties who were often otherwise at odds with one another:

  "OTOH, the workaround you described in [62720#5 [1]] doesn't sound too
  awful to me, given that this problem exists for a while and is not
  specific to Eglot." [2]

  "So we have the following alternatives for the way forward: [...]
  install your changes on master only, and leave the problem of updating
  a core package unsolved in Emacs 29 (with the workaround mentioned in
  the beginning of this bug's discussion available to alleviate the
  problem to some extent)" [3]

  "The official way of switching from built-in packages to ELPA should
  still be to use the package menu." [4]

  "But selecting the package with I and then installing it will "update"
  it" [5]

  "As we already know, the user can already install a newer version of
  Eglot using the 'list-packages' menu (and picking the exact version
  manually)" [6]

  "Whereas one can always upgrade a built-in package using 'i'
  (package-menu-mark-install) in the list-packages menu" [7]

  "To manually execute an upgrade of one package, one needs to both mark
  the new version for installation (after first scrolling down the list
  to find it), and mark the current version for deletion. This is what
  currently an upgrade consists of." [8]

  "We do. We have commands for upgrading, both in "list-packages", and
  used interactively. Which do the thing of installing the new version
  and removing the old one. Which is what upgrading means in various
  tools, e.g. 'apt'." [9]

  "The bug#62720, reported by me, listed the only workaround that works
  identically in Emacs 2*. Just go to the package menu and press 'I' on
  the package you want to install. Boom, there go the ancient safeguards
  against updating builtin packages." [a]

Thus, because this method, however unfashionable, also seemed the only
one compatible with older Emacsen [b], ERC's documentation adopted it as
its recommended means of upgrading:

  To upgrade, run ‘M-x list-packages <RET>’. In the ‘*Packages*’
  (‘package-menu-mode’) buffer, click the ‘erc’ package link for the
  desired version. If unsure, or if the version column is too narrow to
  tell, try the bottom-most candidate. In the resulting ‘help-mode’
  buffer, confirm the version and click ‘Install’. [c]

And this adoption was made known to the current Emacs maintainers at the
time [d]. Consequently, the language above was indelibly seared into the
fabric of ERC 5.5.0.29 and Emacs 29, not only in doc/misc/erc.texi but
also in various doc strings of user options referencing it. Which leads
me to believe that once ERC 5.6 is released, it'll be the upgrade method
many users inevitably try.

So I guess all of this amounts to my asking if some accommodation can be
made server-side to special-case the massaging of ERC's package metadata
into an agreeable format fully compatible with M-x list-packages RET on
older Emacsen.

Thanks,
J.P.

[1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-04/msg00419.html
[2] https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-04/msg00635.html
[3] https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-04/msg00734.html
[4] https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-06/msg00398.html
[5] https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-04/msg01040.html
[6] https://lists.gnu.org/archive/html/emacs-devel/2023-04/msg00511.html
[7] https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-04/msg00911.html
[8] https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-04/msg01396.html
[9] https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-04/msg01435.html
[a] https://lists.gnu.org/archive/html/emacs-devel/2023-04/msg00519.html
[b] https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-06/msg00436.html
[c] http://elpa.gnu.org/devel/doc/erc.html#Upgrading
[d] https://lists.gnu.org/archive/html/emacs-erc/2023-04/msg00013.html

bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> Its installable via `package-install`, but not from the
>> `package-menu-describe-package` because of this bug in that command.
>
> This indeed works interactively on Emacs 29. Thanks.
>
> However, ERC also supports versions 27 and 28. What's the recommended
> way for folks to upgrade on those Emacsen? The least gruesome thing I
> could conjure up is
>
>   (package-install (car (alist-get 'erc package-archive-contents)))

Do you mean that `package-install` won't work because the package is
already installed?  Hmm... yeah, that'd be a problem.

I can see several ways to "fix" this, but I think the simplest would be
to change

    ;; Maintainer: Amin Bandali <bandali@gnu.org>, F. Jason Park <jp@neverwas.me>

into

    ;; Maintainer: emacs-erc@gnu.org

Would that be a problem?


        Stefan

bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

[J.P.]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Its installable via `package-install`, but not from the
>>> `package-menu-describe-package` because of this bug in that command.
>>
>> This indeed works interactively on Emacs 29. Thanks.
>>
>> However, ERC also supports versions 27 and 28. What's the recommended
>> way for folks to upgrade on those Emacsen? The least gruesome thing I
>> could conjure up is
>>
>>   (package-install (car (alist-get 'erc package-archive-contents)))
>
> Do you mean that `package-install` won't work because the package is
> already installed?  Hmm... yeah, that'd be a problem.
>
> I can see several ways to "fix" this, but I think the simplest would be
> to change
>
>     ;; Maintainer: Amin Bandali <bandali@gnu.org>, F. Jason Park <jp@neverwas.me>
>
> into
>
>     ;; Maintainer: emacs-erc@gnu.org
>
> Would that be a problem?

I'll learn to live with it if Amin (Cc'd) can.

bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

[J.P.]

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

"J.P." <jp@neverwas.me> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>> Its installable via `package-install`, but not from the
>>>> `package-menu-describe-package` because of this bug in that command.
>>>
>>> This indeed works interactively on Emacs 29. Thanks.
>>>
>>> However, ERC also supports versions 27 and 28. What's the recommended
>>> way for folks to upgrade on those Emacsen? The least gruesome thing I
>>> could conjure up is
>>>
>>>   (package-install (car (alist-get 'erc package-archive-contents)))
>>
>> Do you mean that `package-install` won't work because the package is
>> already installed?  Hmm... yeah, that'd be a problem.
>>
>> I can see several ways to "fix" this, but I think the simplest would be

Would one of those several ways possibly include overriding the
`package-desc-extras' :maintainer item scraped by `lm-maintainers' with
a spec item from an elpa-packages entry? I see that support for a
`:maintainer' keyword was recently added, but it appears to serve some
other purpose. Anyway, I've attached a sketch of what I'm trying to
describe, but I'm rather unfamiliar with this program.

Thanks.

>> to change
>>
>>     ;; Maintainer: Amin Bandali <bandali@gnu.org>, F. Jason Park <jp@neverwas.me>
>>
>> into
>>
>>     ;; Maintainer: emacs-erc@gnu.org
>>
>> Would that be a problem?
>
> I'll learn to live with it if Amin (Cc'd) can.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-POC-Allow-overriding-extras-maintainer-with-maint-co.patch --]
[-- Type: text/x-patch, Size: 1949 bytes --]

From 698918eb1b1f25a4b97bf951e69344ea441a8074 Mon Sep 17 00:00:00 2001
From: "F. Jason Park" <jp@neverwas.me>
Date: Tue, 23 Jan 2024 12:56:38 -0800
Subject: [PATCH] [POC] Allow overriding extras maintainer with :maint-compat

* elpa-admin.el (elpaa--supported-keywords): Add `:maint-compat'
to spec.
(elpaa--metadata): Allow overriding `package-desc-extras'
`:maintainer' entry with new `pkg-spec' item `:maint-compat'.
(Bug#68660)
---
 elpa-admin.el | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/elpa-admin.el b/elpa-admin.el
index 9cbc805ba4..07db682085 100644
--- a/elpa-admin.el
+++ b/elpa-admin.el
@@ -1011,7 +1011,7 @@ SPECS is the list of package specifications."
   '(:url :core :auto-sync :ignored-files :release-branch :release
     :readme :news :doc :renames :version-map :make :shell-command
     :branch :lisp-dir :main-file :merge :excludes :rolling-release
-    :maintainer :manual-sync)
+    :maint-compat :maintainer :manual-sync)
   "List of keywords that can appear in a spec.")
 
 (defun elpaa--publish-package-spec (spec)
@@ -1377,7 +1377,12 @@ PKG is the name of the package and DIR is the directory where it is."
                         (advice-add 'lm-header :around lmheader-advice))
                       (package-buffer-info))
                   (advice-remove 'lm-header lmheader-advice)))
-               (extras (package-desc-extras pkg-desc))
+               (extras (let ((m-new (plist-get (cdr pkg-spec) :maint-compat)))
+                         (when m-new
+                           (setf (alist-get :maintainer
+                                            (package-desc-extras pkg-desc))
+                                 m-new))
+                         (package-desc-extras pkg-desc)))
                (version (package-desc-version pkg-desc))
                (keywords (lm-keywords-list))
                ;; (_ (elpaa--version-to-list version)) ; Sanity check!
-- 
2.42.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0001-POC-elpa-packages-erc-Add-maint-compat-item.patch --]
[-- Type: text/x-patch, Size: 842 bytes --]

From f206ac628a43bfacc47e70933a383eda3ae08bdb Mon Sep 17 00:00:00 2001
From: "F. Jason Park" <jp@neverwas.me>
Date: Tue, 23 Jan 2024 13:02:17 -0800
Subject: [PATCH] [POC] * elpa-packages (erc): Add :maint-compat item.

---
 elpa-packages | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/elpa-packages b/elpa-packages
index c73e8a066b..ae22abc02c 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -292,6 +292,8 @@
                                "etc/ERC-NEWS"
                                "COPYING")
   :excludes ("lisp/erc/erc-loaddefs.el" "lisp/erc/ChangeLog.*")
+  :maint-compat ("Amin Bandali <bandali@gnu.org>, F. Jason Park <jp@neverwas.me>"
+                 . "emacs-erc@gnu.org")
   :shell-command "(echo '@set ERCDIST from GNU ELPA'; echo '@set EMACSVER') >emacsver.texi"
   :doc "erc.texi"
   :news "ERC-NEWS")
-- 
2.42.0

bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>>> I can see several ways to "fix" this, but I think the simplest would be
> Would one of those several ways possibly include overriding the
> `package-desc-extras' :maintainer item scraped by `lm-maintainers' with
> a spec item from an elpa-packages entry? I see that support for a
> `:maintainer' keyword was recently added, but it appears to serve some
> other purpose. Anyway, I've attached a sketch of what I'm trying to
> describe, but I'm rather unfamiliar with this program.

Hmm... this requires manual work per package, and it drops support for
multiple maintainers altogether, so I'd rather not go there.  I was
thinking instead of making `:maintainer` hold only a single item (the
improper list thingy) and use `:maintainers` to hold the list of
maintainers when there's more than one, which would be more
backward compatible and would solve the problem for all packages.


        Stefan

bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

[J.P.]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> I can see several ways to "fix" this, but I think the simplest would be
>> Would one of those several ways possibly include overriding the
>> `package-desc-extras' :maintainer item scraped by `lm-maintainers' with
>> a spec item from an elpa-packages entry? I see that support for a
>> `:maintainer' keyword was recently added, but it appears to serve some
>> other purpose. Anyway, I've attached a sketch of what I'm trying to
>> describe, but I'm rather unfamiliar with this program.
>
> Hmm... this requires manual work per package, and it drops support for
> multiple maintainers altogether, so I'd rather not go there.  I was
> thinking instead of making `:maintainer` hold only a single item (the
> improper list thingy) and use `:maintainers` to hold the list of
> maintainers when there's more than one, which would be more
> backward compatible and would solve the problem for all packages.

Yes, what you describe definitely seems preferable. So, I guess
`:maintainer' (singular) will always be populated no matter what, for
the benefit of legacy clients who only speak the one. And newer clients
will be taught to always first check `:maintainers' (plural).

Please let me know if anything is required from ERC to make this a
reality. And, of course, I very much appreciate your taking the time.

bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

[Amin Bandali]

J.P. writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>>> I can see several ways to "fix" this, but I think the simplest would be
>>> Would one of those several ways possibly include overriding the
>>> `package-desc-extras' :maintainer item scraped by `lm-maintainers' with
>>> a spec item from an elpa-packages entry? I see that support for a
>>> `:maintainer' keyword was recently added, but it appears to serve some
>>> other purpose. Anyway, I've attached a sketch of what I'm trying to
>>> describe, but I'm rather unfamiliar with this program.
>>
>> Hmm... this requires manual work per package, and it drops support for
>> multiple maintainers altogether, so I'd rather not go there.  I was
>> thinking instead of making `:maintainer` hold only a single item (the
>> improper list thingy) and use `:maintainers` to hold the list of
>> maintainers when there's more than one, which would be more
>> backward compatible and would solve the problem for all packages.
>
> Yes, what you describe definitely seems preferable. So, I guess
> `:maintainer' (singular) will always be populated no matter what, for
> the benefit of legacy clients who only speak the one. And newer clients
> will be taught to always first check `:maintainers' (plural).
>
> Please let me know if anything is required from ERC to make this a
> reality. And, of course, I very much appreciate your taking the time.
>

Sorry I'm a bit out of the loop & probably missing some context here.
I think I'd prefer to keep the personal names in ERC's Maintainer(s)
field if possible, but if it's too much of a hassle and/or impossible
then of course that's a different story.  I'll defer to J.P. and you
to go forward with whatever works best.

Thanks,
-a

bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Yes, what you describe definitely seems preferable. So, I guess
> `:maintainer' (singular) will always be populated no matter what, for
> the benefit of legacy clients who only speak the one. And newer clients
> will be taught to always first check `:maintainers' (plural).

I'd rather have only one of the two (either `:maintainer` or
`:maintainers`) but not both at the same time.  The downside for those
few multi-maintainer packages is fairly small (its only impact is that
`describe-package` will not show the maintainers, which is what we've
had for many years).

> Please let me know if anything is required from ERC to make this a
> reality. And, of course, I very much appreciate your taking the time.

Nothing specific on ERC's side, no.
But patches for `elpa-admin.el` and for Emacs would be welcome (tho
extra time would be welcome as well :-)


        Stefan

bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

[J.P.]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Yes, what you describe definitely seems preferable. So, I guess
>> `:maintainer' (singular) will always be populated no matter what, for
>> the benefit of legacy clients who only speak the one. And newer clients
>> will be taught to always first check `:maintainers' (plural).
>
> I'd rather have only one of the two (either `:maintainer` or
> `:maintainers`) but not both at the same time.  The downside for those
> few multi-maintainer packages is fairly small (its only impact is that
> `describe-package` will not show the maintainers, which is what we've
> had for many years).

If we're only to choose one and also preserve compatibility, wouldn't it
have to be `:maintainers' (plural)? Trying this out on Emacs 28 with
package menu item

  _erc_ 5.6snapshot0.20240124.205832 available devel An Emacs ...

(specifically, by swapping out the `:maintainer' item in the extras slot
of ERC's `package-archive-contents' entry with an otherwise identical
`:maintainers' item), I'm able to successfully advance to the next
screen:

  Package erc is available.

       Status: Available from devel -- Install
      Archive: devel
      Version: 5.6snapshot0.20240124.205832
       Commit: b5d36efa5777e4cc6db1067d58224d676cedbdd3
      Summary: An Emacs Internet Relay Chat client
     Requires: emacs-27.1, compat-29.1.4.4
      Website: https://www.gnu.org/software/emacs/erc.html
     Keywords: irc chat client internet 
       Author: Alexander L. Belikoff <alexander@belikoff.net>
  Other versions: 5.5 (gnu), 5.5.0.29.1 (builtin).

I can only assume doing the same with the contents of erc-pkg.el in the
downloaded tarball would additionally allow me to view the refreshed
help-mode buffer after installation. I've tried simulating this by
updating ERC's entry in `package-alist'. (IIUC, instead of passing along
the `package-desc' object from `package-archive-contents',
`package-install-button-action' elects to have `describe-package-1' look
up the associated value anew in `package-alist', perhaps because it's
seen as more recent or more authoritative, having just been read in by
`package-load-descriptor' from erc-pkg.el.) In any case, this gives me:

  Package erc is installed.

       Status: Installed in ‘erc-5.6snapshot0.20240124.205832/’,
               shadowing a built-in package. Delete

If I haven't overlooked anything, then perhaps changing `:maintainer' to
`:maintainers' (plural) presents an agreeable solution.

>> Please let me know if anything is required from ERC to make this a
>> reality. And, of course, I very much appreciate your taking the time.
>
> Nothing specific on ERC's side, no.
> But patches for `elpa-admin.el` and for Emacs would be welcome
> (tho extra time would be welcome as well :-)

As far as patches go, I unfortunately remain rather uninitiated to the
mysteries of this package system and doubt I can up my game sufficiently
enough to amount to anything more than a sad annoyance. However, I can
try harassing other package.el folk to see if any among them might bend.
Thanks.

bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

[J.P.]

Hi Philip,

"J.P." <jp@neverwas.me> writes:

>>> Please let me know if anything is required from ERC to make this a
>>> reality. And, of course, I very much appreciate your taking the time.
>>
>> Nothing specific on ERC's side, no.
>> But patches for `elpa-admin.el` and for Emacs would be welcome
>> (tho extra time would be welcome as well :-)
>
> As far as patches go, I unfortunately remain rather uninitiated to the
> mysteries of this package system and doubt I can up my game sufficiently
> enough to amount to anything more than a sad annoyance. However, I can
> try harassing other package.el folk to see if any among them might bend.
> Thanks.

You seem to be among the more active Emacs contributors in and around
package.el and GNU ELPA, so I suppose I'm asking if you wouldn't mind
weighing in on this when you get a chance.

To summarize, I've belatedly discovered that once ERC 5.6 is released,
the more-or-less widely acknowledged [1] "baseline" package-upgrade
method (of manually navigating the `package-menu-mode' UI from M-x
list-packages) won't actually work on any ERC-supported Emacs release
(currently 27+) even though it's the one method recommended in ERC's
docs (expressly because it was perceived as being fail-safe). And while
C-u M-x package-install RET does in fact work on Emacs 29, it's sadly
not documented in the ERC manual that ships with 29.2.

Stefan has suggested renaming the `:maintainer' item in the `extras'
slot of `package-desc' objects to `:maintainers' (plural). IIUC, this
would have the effect of solving the issue by omitting the "Maintainer:"
line item in *Help* buffers produced by `package-menu-describe-package'
and friends for all packages on all Emacs versions below 30.1. Full
remediation would, I think, also require that foo-pkg.el files and
/archive-contents data hosted on elpa.gnu.org reflect the newer format.

To help move this process along, Stefan has called for patches, but I
unfortunately am unable to reciprocate because I lack the wherewithal.
Hoping you're able to assist in this regard either directly, with code,
or by pointing out specific areas in the Emacs code base (and possibly
elpa-admin's as well) that would need addressing.

TIA,
J.P.

[1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-01/msg01575.html

bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

[Philip Kaludercic]

"J.P." <jp@neverwas.me> writes:

> Hi Philip,
>
> "J.P." <jp@neverwas.me> writes:
>
>>>> Please let me know if anything is required from ERC to make this a
>>>> reality. And, of course, I very much appreciate your taking the time.
>>>
>>> Nothing specific on ERC's side, no.
>>> But patches for `elpa-admin.el` and for Emacs would be welcome
>>> (tho extra time would be welcome as well :-)
>>
>> As far as patches go, I unfortunately remain rather uninitiated to the
>> mysteries of this package system and doubt I can up my game
>> sufficiently
>> enough to amount to anything more than a sad annoyance. However, I can
>> try harassing other package.el folk to see if any among them might
>> bend.
>> Thanks.
>
> You seem to be among the more active Emacs contributors in and around
> package.el and GNU ELPA, so I suppose I'm asking if you wouldn't mind
> weighing in on this when you get a chance.
>
> To summarize, I've belatedly discovered that once ERC 5.6 is released,
> the more-or-less widely acknowledged [1] "baseline" package-upgrade
> method (of manually navigating the `package-menu-mode' UI from M-x
> list-packages) won't actually work on any ERC-supported Emacs release
> (currently 27+) even though it's the one method recommended in ERC's
> docs (expressly because it was perceived as being fail-safe). And while
> C-u M-x package-install RET does in fact work on Emacs 29, it's sadly
> not documented in the ERC manual that ships with 29.2.
>
> Stefan has suggested renaming the `:maintainer' item in the `extras'
> slot of `package-desc' objects to `:maintainers' (plural). IIUC, this
> would have the effect of solving the issue by omitting the "Maintainer:"
> line item in *Help* buffers produced by `package-menu-describe-package'
> and friends for all packages on all Emacs versions below 30.1. 

That also seems to be the best idea to me as well.

>                                                                Full
> remediation would, I think, also require that foo-pkg.el files and
> /archive-contents data hosted on elpa.gnu.org reflect the newer format.

I am not familiar with ERC's infrastructure, shouldn't this happen
automatically?

> To help move this process along, Stefan has called for patches, but I
> unfortunately am unable to reciprocate because I lack the wherewithal.
> Hoping you're able to assist in this regard either directly, with code,
> or by pointing out specific areas in the Emacs code base (and possibly
> elpa-admin's as well) that would need addressing.

I could help, but I don't understand what is going on well enough to
produce any concrete patches.

> TIA,
> J.P.
>
> [1]
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-01/msg01575.html

bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

[J.P.]

Philip Kaludercic <philipk@posteo.net> writes:

> "J.P." <jp@neverwas.me> writes:
>
>> Stefan has suggested renaming the `:maintainer' item in the `extras'
>> slot of `package-desc' objects to `:maintainers' (plural). IIUC, this
>> would have the effect of solving the issue by omitting the "Maintainer:"
>> line item in *Help* buffers produced by `package-menu-describe-package'
>> and friends for all packages on all Emacs versions below 30.1. 
>
> That also seems to be the best idea to me as well.

Nice. And to be clear, by 'omitting the "Maintainer:" line', I meant
only WRT the `describe-package' results in Emacs and (hopefully) not the
web pages at http://elpa.gnu.org/packages/foo.html, etc.

>
>>                                                                Full
>> remediation would, I think, also require that foo-pkg.el files and
>> /archive-contents data hosted on elpa.gnu.org reflect the newer format.
>
> I am not familiar with ERC's infrastructure, shouldn't this happen
> automatically?

Yes, automatically. But I think elpa-admin would still need a shim, at
least until such time as the Emacs running on the production instance is
upgraded to 30.1 (or 29.3, if such a thing ever materializes). Not sure
if it's Stefan or the GNU infra people who control this.

>
>> To help move this process along, Stefan has called for patches, but I
>> unfortunately am unable to reciprocate because I lack the wherewithal.
>> Hoping you're able to assist in this regard either directly, with code,
>> or by pointing out specific areas in the Emacs code base (and possibly
>> elpa-admin's as well) that would need addressing.
>
> I could help, but I don't understand what is going on well enough to
> produce any concrete patches.

Thanks. I myself don't understand the whole picture either, only what's
readily apparent from observed behavior. I mean, I guess I can give it a
shot, but I'll mostly be flying blind.

>
>> TIA,
>> J.P.
>>
>> [1]
>> https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-01/msg01575.html

bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

OK, OK, I'll see if I can find some time&motivation to work on this.
It shouldn't be very hard,


        Stefan


J.P. [2024-02-14 11:15:06] wrote:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> "J.P." <jp@neverwas.me> writes:
>>
>>> Stefan has suggested renaming the `:maintainer' item in the `extras'
>>> slot of `package-desc' objects to `:maintainers' (plural). IIUC, this
>>> would have the effect of solving the issue by omitting the "Maintainer:"
>>> line item in *Help* buffers produced by `package-menu-describe-package'
>>> and friends for all packages on all Emacs versions below 30.1. 
>>
>> That also seems to be the best idea to me as well.
>
> Nice. And to be clear, by 'omitting the "Maintainer:" line', I meant
> only WRT the `describe-package' results in Emacs and (hopefully) not the
> web pages at http://elpa.gnu.org/packages/foo.html, etc.
>
>>
>>>                                                                Full
>>> remediation would, I think, also require that foo-pkg.el files and
>>> /archive-contents data hosted on elpa.gnu.org reflect the newer format.
>>
>> I am not familiar with ERC's infrastructure, shouldn't this happen
>> automatically?
>
> Yes, automatically. But I think elpa-admin would still need a shim, at
> least until such time as the Emacs running on the production instance is
> upgraded to 30.1 (or 29.3, if such a thing ever materializes). Not sure
> if it's Stefan or the GNU infra people who control this.
>
>>
>>> To help move this process along, Stefan has called for patches, but I
>>> unfortunately am unable to reciprocate because I lack the wherewithal.
>>> Hoping you're able to assist in this regard either directly, with code,
>>> or by pointing out specific areas in the Emacs code base (and possibly
>>> elpa-admin's as well) that would need addressing.
>>
>> I could help, but I don't understand what is going on well enough to
>> produce any concrete patches.
>
> Thanks. I myself don't understand the whole picture either, only what's
> readily apparent from observed behavior. I mean, I guess I can give it a
> shot, but I'll mostly be flying blind.
>
>>
>>> TIA,
>>> J.P.
>>>
>>> [1]
>>> https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-01/msg01575.html

bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

[J.P.]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> OK, OK, I'll see if I can find some time&motivation to work on this.
> It shouldn't be very hard,
>

And all the children say: "Thank you Uncle Stefan."