Repository navigation
Description
Tracking issue for applying importlib_metadata changes to importlib.metadata in 3.16, continuing the pattern of #132947 (3.15) and #117089 (3.13).
This covers importlib_metadata 10.0.0, a change in functionality rather than a fix:
-
Shared protocols for consumers.
IDistributionandIPackagePathjoin
the existingPackageMetadatain_meta.py, and the functions returning
distributions and files are annotated with them. A consumer can target one
interface acrossimportlib.metadataand the backport instead of either
library's concrete classes, which is what a custom provider's objects
require: the provider serves consumers of both libraries and cannot subclass
its way into satisfying both (API incompatibility withimportlib.metadata(or at least the API is not type-safe?) importlib_metadata#486,
Enforce local versions of objects and introduce shared protocols importlib_metadata#505). All three protocols are
@runtime_checkable, soisinstanceanswers the question without
evaluating a distribution's properties on 3.12 and later.What does not come downstream is the other half of that release. The backport
substitutes its own classes for theimportlib.metadataobjects a provider
supplies, and warns where a provider's class omits a memberIDistribution
requires; both live in its_compatpackage, which is excluded from the
port. Only the protocols those mechanisms are defined against are synced, so
the guidance for providers is documented here as the backport's behavior
(Expand documentation for importlib.metadata custom providers to include caveats regarding backports #123976).
Activity
gh-160386: Apply changes from importlib_metadata 9.1 (#160387)
pythongh-160386: Apply changes from importlib_metadata 10.0