From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Phil Sainty <psainty@orcon.net.nz>
Cc: Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org
Subject: Re: ELPA and built-in packages
Date: Mon, 01 Nov 2021 08:11:13 -0400 [thread overview]
Message-ID: <jwvpmrkf5b9.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <92eb2e1ecc93054b2904c406578f11e4@webmail.orcon.net.nz> (Phil Sainty's message of "Mon, 01 Nov 2021 20:44:52 +1300")
Phil Sainty [2021-11-01 20:44:52] wrote:
> On 2021-11-01 07:55, Stefan Monnier wrote:
>> Reality will sometimes disagree, because it depends if `package.el`
>> is truly informed about the built-in package.
>
> What is it about the built-in package that "informs" package.el?
The info is stored in `package--builtin-versions` which is populated
from the autoloads information in `lisp/loaddefs.el`, which is
generated by `lisp/emacs-lisp/autoload.el`:
(when autoload-builtin-package-versions
(let ((version (lm-header "version"))
package)
(and version
(setq version (ignore-errors (version-to-list version)))
(setq package (or (lm-header "package")
(file-name-sans-extension
(file-name-nondirectory file))))
(setq output-start (autoload--setup-output
otherbuf outbuf absfile
load-name outfile))
(let ((standard-output (marker-buffer output-start))
(print-quoted t))
(princ `(push (purecopy
',(cons (intern package) version))
package--builtin-versions))
(princ "\n")))))
> I just did a test with so-long.el and got slightly odd results.
>
> 1. I ran Emacs 27.2 (which includes so-long 1.0) with a fresh profile.
> 2. I then installed v1.1 from
> https://elpa.gnu.org/packages/so-long-1.1.tar.lz
> 3. I then quit and ran Emacs 28 (which includes so-long 1.1.2).
> 4. M-x package-refresh-contents
> 5. M-x package-list-packages
> 6. M-x occur RET so-long
>
> Result:
>
> 3 matches for "so-long" in buffer: *Packages*
> 310: so-long 1.1.2 available gnu
> 388: so-long 1.1 installed
> 444: so-long 1.0 built-in
>
> The actual so-long functionality is good (the built-in version 1.1.2 is
> used in practice, as desired), but that listing is definitely confused.
Quite odd, indeed. Any chance your `loaddefs.el` was stale?
Try `(cd lisp; make autoloads); make` to rebuild your Emacs after having
explicitly refreshed your autoloads.
You can also try `grep package--builtin-versions **/*.el | grep long` ?
Stefan
next prev parent reply other threads:[~2021-11-01 12:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-31 18:08 ELPA and built-in packages Lars Ingebrigtsen
2021-10-31 18:55 ` Stefan Monnier
2021-11-01 7:44 ` Phil Sainty
2021-11-01 8:06 ` Phil Sainty
2021-11-01 12:11 ` Stefan Monnier [this message]
2021-11-01 13:35 ` Lars Ingebrigtsen
2021-11-01 17:50 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvpmrkf5b9.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=larsi@gnus.org \
--cc=psainty@orcon.net.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).