Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpo-43926: Cleaner metadata with PEP 566 JSON support. #25565

Merged
merged 4 commits into from
May 2, 2021

Conversation

jaraco
Copy link
Member

@jaraco jaraco commented Apr 23, 2021

@jaraco
Copy link
Member Author

jaraco commented Apr 23, 2021

Note, this change includes and should be merged after #25297.

@jaraco jaraco marked this pull request as draft April 23, 2021 22:30
@@ -170,6 +170,12 @@ the values are returned unparsed from the distribution metadata::
>>> wheel_metadata['Requires-Python'] # doctest: +SKIP
'>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*'

``PackageMetadata`` also presents a ``json`` attribute that returns
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a Python 3.10 only feature and hence a versionadded directive can be added.

Slightly out of topic, are Distribution objects and metadata attribute immutable? Accessing json attribute from metadata objects repeats the computation though it looks like a computed once attribute so just curious if metadata attribute of Distribution, json attribute etc. can be made a cached_property.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 289665029e (also versionchanged for changes to the interpretation of the metadata).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can be made a cached_property?

Although technically the PackageMetadata object is mutable, the protocol for it doesn't allow for mutation, so it's effectively immutable, so yes, a cached_property could be employed. Such an optimization may be premature, so I'm slightly inclined to defer that concern until a use-case presents itself. I don't feel strongly about it though and would likely accept a PR to importlib_metadata.

@jaraco
Copy link
Member Author

jaraco commented Apr 24, 2021

@warsaw I note also that while we intentionally consolidated importlib.metadata into a single module (#15153), the package has since diversified and the _common module now conflicts with importlib_resources, so I've moved the modules back into a package to avoid the conflict and more clearly separate the concerns.

@jaraco jaraco marked this pull request as ready for review April 24, 2021 14:36
@jaraco jaraco force-pushed the bpo-43926/importlib-metadata-4 branch from 2896650 to a9463bd Compare April 24, 2021 14:56
@jaraco jaraco requested a review from tirkarthi April 30, 2021 20:15
@jaraco
Copy link
Member Author

jaraco commented May 2, 2021

In order to ensure this change is included in the 3.10 release, I'm merging now. Happy to troubleshoot or back out specific behaviors as needed.

@jaraco jaraco merged commit 37e0c78 into master May 2, 2021
@jaraco jaraco deleted the bpo-43926/importlib-metadata-4 branch May 2, 2021 21:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants