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

Use the stdlib importlib.metadata when available #1024

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

eli-schwartz
Copy link

The use of importlib_metadata relies on features that were introduced in python 3.10. Aside for that, it should be fine to use the stdlib directly.

Fixes #773

From #773 (comment):

I think this should at least wait until 3.10 is officially released and is added to Twine's testing matrix.

It's in the testing matrix. More importantly, we are now up to python 3.12 -- there are more versions of non-EOL python that have a suitable stdlib version than don't.

If we do decide to use importlib.metadata, then I think the version check should be done in one place, as suggested in #772 (comment).

I'm not sure I understand, largely because no specific reason was given there. Adding a new module just to wrap one import seems like a very complicated solution for something that doesn't need continual maintenance, and introduces additional stat'ing of the filesystem / opening a bunch more files for reading, to boot. If the concern is about dropping outdated version blocks in just one place, then puypgrade (as previously used in this repo) can make that edit for you. :)

The use of importlib_metadata relies on features that were introduced in
python 3.10. Aside for that, it should be fine to use the stdlib
directly.

Fixes pypa#773
Copy link
Member

@jaraco jaraco left a comment

Choose a reason for hiding this comment

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

This looks fine to me. importlib_metadata 3.6 was included in Python 3.10, so it's unlikely that twine is reliant on features added in later Pythons or releases of importlib_metadata, and the tests seem to confirm that.

@jaraco jaraco closed this Apr 18, 2024
@jaraco jaraco reopened this Apr 18, 2024
@eli-schwartz
Copy link
Author

The refreshed CI has two issues resulting in failures:

  • tests pass but reduce coverage by 1%? 🤷
  • integration failure because of setuptools changes in canonicalization of sdist/wheel filenames.

The coverage thing is interesting because if you could collect coverage data across multiple CI jobs and analyze them together, I bet it would not fail. It's just failing because version-dependent code branches. I know that external services can aggregate coverage data across CI runs (even more useful when you have OS-specific branches!) but I'm unfamiliar with the available options for local analysis inside the action. Maybe copying coverage data to an artifact and analyzing it in a later job?

@jaraco
Copy link
Member

jaraco commented Apr 18, 2024

My vote is to ignore the coverage concerns or exclude them. I hope eventually to learn how to collect the coverage results together, but I haven't yet done so and when I do, I'll do that in jaraco/skeleton and/or coherent-oss and not for one project at a time.

@eli-schwartz
Copy link
Author

Great, works for me. :) I wasn't going to have time to look into that either way.

@sigmavirus24
Copy link
Member

Actually there's a blog post from Hynek that makes lays out how to do this well. It's not hard

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.

Someday: Use importlib.metadata from the standard library
3 participants