[Distutils] Updated drafts of metadata 2.0 (PEP 426 and PEP 440)

[Paul Moore]

On 21 June 2013 12:35, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130621/0fdc5857/attachment.html>