Alternative approach to retrieve Compat symbols

[minad]

Hi Steve,

recently a stub of compat.el got added to Emacs. The stub has the version emacs-major-version.emacs-minor-version.9999 such that Compat is never installed, if the current Emacs version is new enough. This makes sense since in this case the functions provided by Emacs are sufficient and Compat cannot provide more. The idea is that Compat should be free to use if your Emacs is new enough. See https://github.com/emacs-mirror/emacs/commit/db195116a4279521e9cf03c52b7026032461e3e1.

Unfortunately this leads to a problem with the approach we've chosen in #227 for loading the list of symbols defined by Compat. Package-lint throws the error "compat package not installed", since Package-lint expects the "real" Compat package to be around.

There are these solutions to work around this problem:

1. Include the Compat symbol list as part of Package-lint (like stdlib-changes). The downside is that this requires more frequent updates and releases of Package-lint. Maybe one could add a CI job which automatizes the updates, similar to your nix-emacs-ci updater?
2. Package-lint could automatically download the Compat symbol list, for example from https://raw.githubusercontent.com/emacs-compat/compat/package-lint/symbols. I could update the symbol list there from time to time. Problem is that the downloaded list could also get outdated so one would also need an automatic update. But maybe automatic downloads are not desired? They would also hurt offline use.
3. Package-lint could download compat-*.tar from ELPA and extract the data as it does right now.

What do you suggest? Thanks!

[purcell]

Hi, thanks for flagging this!

Option 1 is probably a little more build machinery than would be ideal. The weekly updates in nix-emacs-ci already take some manual intervention, so it's not necessarily a good example to follow.

Re. Option 2, I'd prefer to avoid automatic downloads at runtime.

Option 3 just sounds like an approach for doing Option 1.

On balance, here's what I might suggest:

• Regenerate the changes like we do for stdlib-changes, but not on a manual update
• We'd do that by running a generation script in CI
• That script would run with emacs 28 but install compat 29 to force the ELPA version
• It would use a variation of the current extraction code
• We could then drop the dependency on compat from package-lint
• We should also write a checklist for what to do here when new Emacs versions pop up, because there are a few magic numbers in and around this code and its build scripts

Struggling for time currently so I might not work on this myself imminently.

[minad]

Thanks! I made a first attempt at https://github.com/purcell/package-lint/pull/262. For now I generated data/compat-symbols manually from my local Compat repository. If you like you could merge this soon to solve the imminent problem with Emacs 30 compat.el. We could later try to automatize the symbol extraction.

I think not many people are affected right now (only the ones with a very recent Emacs 30 and package-lint). But I am sure the issue will pop up at some point, either here or on the Compat issue tracker. The number of Emacs master users is surprisingly high, but there is likely also a selection bias, since users who compile their own Emacs may report issues earlier.