search

yaml / pyyaml

Canonical source repository for PyYAML
MIT License
2.55k stars 518 forks source link

PyYAML artifacts uploaded to pypi.org have missing Python-Requires metadata #398

Open ngaya-ll opened 4 years ago

ngaya-ll commented 4 years ago

Although PyYaml's setup.py contains a requires_python field, the pypi.org links do not have the expected data-requires-python anchor attribute (see PEP 503). This creates problems for users of older Python versions as pip uses this information to determine which version to download and install.

For example, on Python 3.4:

$ pip install pyyaml
Collecting pyyaml
  Downloading https://files.pythonhosted.org/packages/64/c2/b80047c7ac2478f9501676c988a5411ed5572f35d1beff9cae07d321512c/PyYAML-5.3.1.tar.gz (269kB)
ERROR: PyYAML requires Python '>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*' but the running Python is 3.4.10

With the correct metadata, pip could automatically select and install PyYAML 5.2, the latest version with Python 3.4 support.

The reason for this issue seems to be that the Requires-Python metadata property was not provided when these artifacts were uploaded. If using setuptools for PyPI uploads, please switch to twine for future releases to ensure full metadata support. See https://packaging.python.org/tutorials/packaging-projects/#uploading-the-distribution-archives

It would be great if you could also fix the metadata for existing artifacts as well, at least from version 5.3 onward. I believe this can be done using the twine register command.

perlpunk commented 4 years ago

I managed the last releases. Unfortunately I don't know much about Python packaging. I was using twine. The packaging steps are still WIP, and I got the steps from @nitzmahone and put it into this branch: https://github.com/yaml/pyyaml/blob/packaging/release-steps

Maybe @nitzmahone can help?

nitzmahone commented 4 years ago

It's actually more complicated than that- the metadata exists properly in the package, but because pyyaml's setup code is so ancient (it's using an unholy marriage of customized distutils and injected setuptools), it prevents the metadata from propagating correctly when publishing to PyPI (even via Twine). I verified a few months back that fully upgrading to setuptools fixes it, but there are changes required to make the heavily customized extension build work properly under setuptools that I haven't had time to make... I think we'd also have to use PyPI's new "yank build" feature to republish updates to older releases that weren't properly declaring the required Python metadata in order to get the desired behavior (and that's assuming that the ancient versions of pip that still work on those dead Python versions will do the right thing). When we get the setup stuff fixed, I'll investigate that to see if it's workable, but it's probably not going to be happening in the next few weeks anyway. In the interim, I'd suggest pinning to an older supported version (though IIRC we haven't actually made any breaking changes yet against 2.6 or 3.4).