Normalize python_requires version specifiers

[zzh1996]

I have the following setup.py file

from setuptools import setup

setup(
    name = "my_test",
    python_requires = '~=2.7'
)

According to setuptools documentation and python official documentation, I can use ~= in python_requires as defined in PEP 440.

After running python setup.py install, PKG-INFO is generated.

$ cat my_test.egg-info/PKG-INFO 
Metadata-Version: 1.2
Name: my-test
Version: 0.0.0
Summary: UNKNOWN
Home-page: UNKNOWN
License: UNKNOWN
Description: UNKNOWN
Platform: UNKNOWN
Requires-Python: ~=2.7

According to PEP 345, only "<", ">", "<=", ">=", "==" and "!=" are allowed in Requires-Python version numbers, which causes the PKG-INFO file to be invalid.

[pganssle]

@zzh1996 What is the preferred behavior? That we would throw an error?

To the extent that this is in scope, it is probably a duplicate of #1390. We don't currently do any metadata validation, likely the right place for this functionality is in packaging, or some similar more generic library.

[pganssle]

I will leave this open for the moment until we create an issue somewhere for tracking what metadata needs to be validated.

[zzh1996]

I think this issue is not related to validating metadata. My python_requires is valid. ~= even appears in the documentation. What you need to do is to convert it to a valid Requires-Python value in PKG-INFO

[pganssle]

@zzh1996 What would it be converted to? Where in the documentation does it say you can use ~= in python_requires?

Edit: Sorry, missed your links, looking now.

[zzh1996]

According to PEP440

For example, the following groups of version clauses are equivalent:

~= 2.2
>= 2.2, == 2.*

~= 1.4.5
>= 1.4.5, == 1.4.*

[benoit-pierre]

I think it's valid: see https://packaging.python.org/specifications/core-metadata/#requires-python. It's definitively valid if we bump the version to 2.1.

[pganssle]

This difference is very strange. I don't like the idea that we need to do this conversion, though I'm fine with us doing it.

[benoit-pierre]

In any case, what's the practical issue? Is there any case were this is not properly supported by other tools?