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

Restore support for pkginfo 1.11 #1123

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

Conversation

jaraco
Copy link
Member

@jaraco jaraco commented Jun 25, 2024

For now, this approach retains the current behavior that an unrecognized metadata version will fail with an error.

This approach splits out the detection based on the version of pkginfo. Starting with pkginfo 1.11, it now properly detects when a metadata version is unrecognized and errors on that condition explicitly. For backward compatibility, until pkginfo 1.11 is the minimum, the check will still provide guidance to consider the metadata version when fields are missing.

Closes #1116

@jaraco jaraco force-pushed the bugfix/1116-pkginfo-warnings branch 5 times, most recently from 53f0216 to 71346e0 Compare June 25, 2024 18:11
@jaraco jaraco marked this pull request as ready for review June 25, 2024 18:13
@jaraco
Copy link
Member Author

jaraco commented Jun 25, 2024

Well, shoot. It seems that after allowing pkginfo 1.11, the type checks are failing. It seems that pkginfo.Distribution.name was str and now is str | None. Same for .version.

twine/package.py Outdated Show resolved Hide resolved
twine/repository.py Outdated Show resolved Hide resolved
@woodruffw
Copy link
Member

Random thought: is there a reason this can't constrain pkginfo ~= 1.11 in pyproject.toml? That would avoid the need for the run-time version check + some of the extra handling in this PR.

@jaraco
Copy link
Member Author

jaraco commented Jun 26, 2024

Random thought: is there a reason this can't constrain pkginfo ~= 1.11 in pyproject.toml? That would avoid the need for the run-time version check + some of the extra handling in this PR.

My thought was that there are probably users still reliant on older versions, so it would be nice to have at least one release transition where users aren't forced to the newer version. I absolutely agree that after twine stabilizes, we might bump the dependency on pkginfo (and remove the compatibility logic). I coded it in such a way as to make it easy to remove the compatibility logic.

I also observed that there's already an open issue #1070 tracking the move to pkginfo 1.10, so that issue would need to be addressed first (or simultaneously) with the move to 1.11.

@jaraco jaraco force-pushed the bugfix/1116-pkginfo-warnings branch 2 times, most recently from 1ca93e2 to a0fdb54 Compare June 26, 2024 14:29
@jaraco jaraco force-pushed the bugfix/1116-pkginfo-warnings branch from a0fdb54 to a0da730 Compare June 26, 2024 14:39
@jaraco
Copy link
Member Author

jaraco commented Sep 6, 2024

I don't understand why the coverage tests are failing. They weren't failing before. Maybe the upstream changes pushed the coverage marginally lower and now these changes push them even lower? Since the coverage failures are for total coverage and not diff coverage, it's difficult for me to see what changes in this PR have contributed to the failing check.

@jaraco
Copy link
Member Author

jaraco commented Sep 6, 2024

Due to #1121, I'm unable to locally assess the coverage issues.

@stefanor
Copy link
Contributor

Applied this PR as a patch, in Debian's twine.

@chadlwilson
Copy link

To get this moving again, perhaps can just reduce the coverage target at

twine/tox.ini

Line 22 in ae71822

python -m coverage report --skip-covered --show-missing --fail-under 97
to 96 since this does not appear to demonstrably reduce the coverage? Maybe just a rounding difference?

@stefanor
Copy link
Contributor

Due to #1121, I'm unable to locally assess the coverage issues.

That's trivially worked around with HOME=/tmp/home/:

--- /tmp/before.coverage	2024-09-25 11:02:57.056573133 +0200
+++ /tmp/after.txt	2024-09-25 11:00:16.951779487 +0200
@@ -8,10 +8,10 @@
 twine/__init__.py             14      1      4      2    83%   39, 46->exit
 twine/cli.py                  34      2      6      2    90%   22, 86
 twine/commands/upload.py      95      1     39      1    99%   103
-twine/package.py             159      5     55      6    95%   27, 111, 139, 227, 306->exit, 312
-twine/repository.py          118      3     46      4    96%   90, 104->exit, 108->exit, 164->exit, 198, 250
+twine/package.py             178      6     67      7    95%   39, 132, 152, 167, 269, 348->exit, 354
+twine/repository.py          118      3     46      4    96%   90, 104->exit, 108->exit, 167->exit, 201, 253
 twine/settings.py             82      4     18      0    96%   333-341
 twine/utils.py               138      1     49      0    99%   330
 twine/wininst.py              38     26     16      0    26%   15-17, 21-25, 28-57
 ----------------------------------------------------------------------
-TOTAL                       2033     48    618     17    97%
+TOTAL                       2058     49    634     18    97%

@stefanor
Copy link
Contributor

The new addition is:

https://github.com/pypa/twine/pull/1123/files#diff-30ee60b48548622c54dfa266e095021f403ad23ab4848c74b2deed5df329ae00R152

            if cls._pkginfo_before_1_11():
                msg += (
                    "\n"
                    "Make sure the distribution includes the files where those fields "
                    "are specified, and is using a supported Metadata-Version: "
                    f"{', '.join(supported_metadata)}."
                )

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.

[self tests] test_pkginfo_returns_no_metadata fails against pkginfo 1.11.0
4 participants