search

purcell / package-lint

A linting library for elisp package metadata
GNU General Public License v3.0
192 stars 33 forks source link

Should package-lint fallback to previous minor release? #269

Open manphiz opened 5 months ago

manphiz commented 5 months ago

In light of https://github.com/purcell/package-lint/issues/266 and https://github.com/purcell/package-lint/issues/268, it looks like package-lint will fail checking when a new Emacs point release is available but the mapping is not updated. I wonder whether it's possible to temporarily fallback to use information from a previous point release (or a previous major release if possible) so that it's not broken by each Emacs release?

purcell commented 5 months ago

Can you say more about what goes wrong when you use package-lint in a newer Emacs than it expects? It wasn't quite clear in #266. I think it's perhaps related to versions of built-in packages?

manphiz commented 5 months ago

Ah yes sorry I didn't provide an example of the failure. I noticed this when working on exec-path-from-shell which downloads the latest snapshot of package-lint during building, and I was trying to use a local package-lint version instead. This is to make the build process not reliant on Internet access so that it doesn't fail the reproducibility test for Debian packaging.

What happened first was when I was testing with Emacs 29.2 and package-lint 0.21 I saw this error:

exec-path-from-shell.el:9:38: error: Package cl-lib is not installable.

And obviously the snapshot version when downloaded worked, as well as a locally prepared one, and I realized it was because 0.21 doesn't have the mapping for 29.2 yet, which was when I requested a new release in #266.

And then, I tried with 0.22 a few days ago and was surprised that I was met with the exact same error, again! And then I realized that it was because of the emergency Emacs release of 29.3, which package-lint 0.22 didn't have either lol.

All that said, it looks like currently the usability of package-lint is tightly connected with the release of Emacs, and I wonder whether that's necessary, especially with point releases? Surely there may be something new, but I would expect between point releases it should be largely compatible, so before a mapping for 29.3 is provided, it may try a previous point release (e.g. 29.2) instead, and with a warning if desired, but not to report an error.

Wdyt?

purcell commented 5 months ago

Ah, I feel like that error wasn't actually about a missing mapping for 29.2. There was a separate change made in https://github.com/purcell/package-lint/commit/bf2b091b0033e4c8098a9c73734d3968c648292c: prior to that commit, package-lint didn't consider any built-in packages as installable. It's weird if you were getting the same message with 0.22: there's nothing about package availability that is specific to Emacs versions

manphiz commented 5 months ago

Hmm, indeed. I found that what you mentioned was supposed to be fixed by https://github.com/purcell/package-lint/commit/bf2b091b0033e4c8098a9c73734d3968c648292c. However, when I look at package-alist I don't seem to find cl-lib there. So when I was testing back then it somehow didn't report not founding cl-lib in some conditions.

So it looks like some packages that are built-in will not show up in package-alist, which may need some special handling? Examples come to mind are cl-lib, generic-x, flyspell, etc.

manphiz commented 5 months ago

It looks like built-in packages are listed in package--builtins or package--builtin-versions, which may worth checking. Though by naming conventions these are internal, so not sure whether there is a public counterpart.