I think the wsgiref issue was that it wasn't in site-packages and so couldn't be removed or upgraded. Having the dist-info available and putting them in site-packages (or a new directory?) lets us handle querying/replacing/removing using the existing tools we use for distribution.

Also, I think the version numbers do need to be independent of Python version in case nothing changes between releases. If you develop something using statistics==3.7, but statistics==3.6 is identical, how do you know you can put the lower constraint? Alternatively, if it's statistics==1.0 in both, people won't assume it has anything to do with the Python version.

The tricky part here is when everything is in the one repo and everyone implicitly uses the latest version for development, you get the reproducibility issues Barry mentioned earlier. If they're separate and most people have pinned versions, that goes away.

Top-posted from my Windows Phone
From: Paul Moore
Sent: ‎7/‎6/‎2016 2:32
To: Petr Viktorin
Cc: Python-Dev
Subject: Re: [Python-Dev] Breaking up the stdlib (Was: release cadence)

On 6 July 2016 at 10:01, Petr Viktorin <encukou@gmail.com> wrote:
> 4) Adjust pip to ignore installed stdlib modules that are present, so
> distributions can depend on "statistics" and not "statistics if
> python_ver<3.4". (statistics is just an example, obviously this would
> only work for modules added after the PEP). For missing stdlib modules,
> pip should fail with the message from 1). (Unless the "pip upgrade
> asynciio" proposal goes through, in which case install the module if
> it's upgradable).

A couple of comments here.

1. Projects may still need to depend on "statistics from Python 3.6 or
later, but the one in 3.5 isn't good enough". Consider for example
unittest, where projects often need the backport unittest2 to get
access to features that aren't in older versions.

2. This is easy enough to do if we make stdlib modules publish version
metadata. But it does raise the question of what the version of a
stdlib module is - probably Python version plus a micro version for
interim updates. Also, I have a recollection of pip having problems
with some stdlib modules that publish version data right now
(wsgiref?) - that should be checked to make sure this approach would
work.

> Looks like it's time for a PEP.

Probably - in principle, something like this proposal could be
workable, it'll be a matter of thrashing out the details (which is
something the PEP process is good at).

Paul
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org