On 21 June 2013 12:35, Nick Coghlan
The quick compatibility check is actually part of the wheel file naming specification (it's covered by the compatibility tags defined in PEP 425).
Yes, I was thinking more of the sdist side - and also of how a pure Python package can specify whether separate wheels are needed for Python 2 and Python 3, for example. There's a wheel-specific setup.cfg extension for this, but should it be in the metadata spec?
For PEP 426, I originally retained the separate "Requires-Python" field, but eventually realised it was redundant given the "supports_environments" field (http://www.python.org/dev/peps/pep-0426/#supports-environments) and the "python_version" and "python_full_version" variables in environment markers. It gets a little clumsy if you want to express a Python version constraint *and* a platform constraint (due to the implicit or), but the current approach does have the virtue of handling cases where version requirements differ between platforms. For example, if you need atomic renaming capabilities, then they've been available on POSIX systems since pretty much forever, but on Windows you need Python 3.3 so you can have access to os.replace. In the current PEP, that might look like:
"supports_environments": ["sys_platform != 'win32' and python_version >= 2.6", "sys_platform == 'win32' and python_version >= 3.3"]
Yes, but that's very much the "power user" end of the spectrum, as you mentioned before.
If your package was source compatible between 2.6, 2.7 and 3.3+ you might say:
"supports_environments": ["python_version == 2.6", "python_version == 2.7", "python_version >= 3.3"]
More often than not, my thinking is more at the level of "did I take the time to make the code dual-version compatible" - things like putting brackets round print arguments. Or simply "will I accept bug reports for both Python 2 and Python 3, even though I only really test on Python3". The supports_environments tag seems too precise for that sort of very broad brush approach. However, looking at the PEP, I realise I didn't actually update the
remaining text to reflect that realisation - I just deleted the old text that was no longer applicable. I'll add an example that shows using "supports_environments" to specify a minimum Python version in a way installation tools are expected to check.
I'll also make it clearer that "supports_environments" describes what the *sdist* supports. Generating a wheel file may limit it further (as indicated by the compatibility tags).
That sounds good. I'd suggest examples like twisted (doesn't support Python 3 yet), virtualenv (supports Python 2.6 or greater, including 3.x) and maybe something that is purely for Python 3. I'd also like to see a paragraph explaining that installers SHOULD at least respect python version specs (even if they don't handle the full environment marker spec). I'm not sure how practical it would be to require that sort of partial support, though, which is my main reservation about using the environment spec for this. (I think respecting language version specs is important, but the full environment spec is no more than a nice to have). Also, it seems to me that wheel could use the Python version spec to generate appropriate compatibility tags. Again, that's not possible for tags in their full generality, but is possible for "Python version only" tags. And again, I'd like to see something saying that wheel generators should do this (otherwise, there's a duplication somewhere as this information would need to be specified elsewhere in a generator-specific manner, like the setup.cfg extension I mentioned above). Paul