pypa / twine

Utilities for interacting with PyPI
https://twine.readthedocs.io/
Apache License 2.0
1.61k stars 308 forks source link

Twine should require pkginfo > 1.10 #1070

Open pfmoore opened 7 months ago

pfmoore commented 7 months ago

Is there an existing issue for this?

What keywords did you use to search existing issues?

None, I scanned the closed issue list manually and found it.

Please describe why your using this option

This is linked to issue https://github.com/pypa/twine/issues/1059

Without depending on pkginfo > 1.10, existing users of twine won't get the new pkginfo version by upgrading twine (pip does not upgrade dependencies by default unless necessary). As a result, users upgrading twine because they are getting an error when using metadata 2.3, will still get the issue after the upgrade, and will be confused as to how to address the problem. See https://github.com/pypa/packaging-problems/issues/735 for such a case.

Anything else you'd like to mention?

No response

henryiii commented 7 months ago

FYI, maturin and now hatchling are producing metadata 2.3.

sigmavirus24 commented 7 months ago

I don't believe we typically update the floor for dependencies like pkginfo because that typically gets us into hot water with distributors. We can, but I'm not sure it's worth the effort. I'm not certain the adoption of hatchling or maturin is enough that folks will encounter this.

henryiii commented 7 months ago

Small comment: Hatchling is the third most popular build backend on PyPI (after setuptools and Poetry) - it's the most popular backend to only support PEP 621 and maturin is the most popular compiled build backend (not counting setuptools). I would also assume other backends will update at some point now that PyPI supports 2.3 - if pyproject-metadata updates for example, that would affect pdm-backend, scikit-build-core, and meson-python.

Not saying it should be updated, but just commenting on this aspect of the reply. I agree that a tight floor would also cause issues (maybe good ones though?)

umarbutler commented 7 months ago

On 15 March, I updated a package using py -m twine upload --repository pypi dist/* and experienced no issues. Today, I built a new package, seemingly having not upgraded any of my build tools (although perhaps it is possible I did?) and experienced this issue: InvalidDistribution: Metadata is missing required fields: Name, Version.. This persisted even after upgrading my twine and trying Python 11 instead of 12. Only after upgrading pkginfo was the issue fixed. A higher version of pkginfo should be a requirement to ensure that this doesn't happen to others. At the very least, twine's error message should mention that upgrading pkginfo will probably solve the issue.

Related issues I have located are as follows:

pfmoore commented 7 months ago

+1 for at least updating the error message to suggest manually upgrading pkginfo.

umarbutler commented 7 months ago

I don't believe we typically update the floor for dependencies like pkginfo because that typically gets us into hot water with distributors. We can, but I'm not sure it's worth the effort. I'm not certain the adoption of hatchling or maturin is enough that folks will encounter this.

@sigmavirus24 I’d suggest having a look at all the issues I referenced, there are a number of us that have already begun encountering problems. Hatchling is pretty popular.

jaimergp commented 7 months ago

This should be pkginfo>=1.10, right? 1.10 included, I mean.

jaraco commented 4 months ago

It seems that pkginfo 1.11 has added forward-compatibility for future metadata versions (along with a warning). Assuming #1123 is adopted, it's been suggested that twine set pkginfo >= 1.11 as the floor, after which the need to keep bumping the floor with metadata revisions goes away. As it currently stands, users get a more informative error message about "supported metadata versions", which provides a somewhat better signal when the metadata version is missing or unrecognized. Perhaps it makes sense to bump the minimum to >= 1.11 soonish to get the warning behavior for everyone.