Subject: bug#78844: 30.1; feature request: public interface for querying builtin packages and versions

From: Xiyue Deng <[email-masked]>
Date: Tue, 24 Jun 2025 12:54:36 -0700

Hi Stefan,

Stefan Monnier <[email-masked]> writes:

>> Thanks for pre-approving!  I have attached a draft patch for adding
>> those functions.  A slight change is to query `package--builtins' for
>> builtin package names as it contains a larger list of builtin packages
>> that may not have a version defined in `package--builtin-versions'.
>
> Normally, all the names in `package--builtins` that are not in
> `package--builtin-versions` are for packages which exist only within
> Emacs (and the meaning of "package" tends to be rather poorly defined
> for them), so I'm not sure we want to go there.  It has not been
> designed for dependency checking, but only to help users find useful
> packages among those bundled with Emacs, IOW it's meant for human
> consumption, not machine consumption.
>
> `package--builtin-versions' is much more reliable and meaningful,
> in comparison.
>

Ack.  I was puzzled by the relationship between `package--builtins' and
`package--builtin-versions'.  It looks like the latter is exactly for
our use case.

>> Also, for completeness, I actually find there is
>> a `package-built-in-p' function for checking built-in packages.
>> But there is no way to get a complete list of builtin packages, so
>> package-builtin-packages is still needed.
>
> What is the use case for getting a list?
>
> AFAICT in your example scenario of a package depending on Org-9.7, you
> just need to check the version of that one builtin package.
>

This is mainly used for external tooling.  Having a list of
bundled/builtin packages and versions can help distribution package
manager, e.g. APT in Debian, to manage dependencies easier (as mentioned
in my first email).  We need to generate the package information and
store it in the Debian package info for those tools to use as they
cannot query Emacs in runtime.

>> I also don't check whether a package is builtin in the added
>> `package-builtin-package-version' function and return nil for both
>> non-builtin packages and builtin packages without a version, as we can
>> use `package-built-in-p' to check the former.
>
> I don't understand what you mean.  The code I see looks up
> `package--builtin-versions` so it knows that the package
> is builtin.  What am I missing?
>

Sorry I was a bit unclear.  There are packages that are in
`package--builtins' but not in `package--builtin-versions', so
technically there are packages that are builtin but without a version.
So in my draft implementation I didn't distinguish whether a given
package is not builtin (not in both package--* variables) or is builtin
but didn't have a version.

Now that it was clear that we should just depend on
`package--builtin-versions' this is no longer an issue (also the
question I had in my last email is resolve now that we don't use
`package--builtins' anymore).

>         Stefan

-- 
Regards,
Xiyue Deng