Re: [Python-Dev] Breaking up the stdlib (Was: release cadence)
On 6 July 2016 at 14:55, Steve Dower <steve.dower@python.org> wrote:
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.
That's the one. Thanks for the reminder. So either we move the stdlib (or parts of it) into site-packages, or pip needs to learn to handle a versioned stdlib. Cool.
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.
This boils down to whether we want to present the stdlib as a unified object tied to the Python release, or a set of modules no different from those on PyPI, that happen to be shipped with Python. I prefer the former view (it matches better how I think of "batteries included") whereas it looks like you prefer the latter (but don't see that as being in conflict with "batteries included"). Debating this in the abstract is probably not productive, so let's wait for a concrete PEP to thrash out details like this. Paul
Thrashing out details should go on the workflow SIG, and I guess I'm the obvious candidate to push it asking. But given my own time constraints right now, I'm not going to dive into details if the high level concept (stdlib packages can be individually updated by end users apart from a full CPython release) is at issue. Once there seems to be general agreement that this is a worthy goal, I'll see if I can put down details for how I would implement it. (And go join the core-workflow list, I guess :) ) Top-posted from my Windows Phone -----Original Message----- From: "Paul Moore" <p.f.moore@gmail.com> Sent: 7/6/2016 7:10 To: "Steve Dower" <steve.dower@python.org> Cc: "Petr Viktorin" <encukou@gmail.com>; "Python-Dev" <python-dev@python.org> Subject: Re: [Python-Dev] Breaking up the stdlib (Was: release cadence) On 6 July 2016 at 14:55, Steve Dower <steve.dower@python.org> wrote:
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.
That's the one. Thanks for the reminder. So either we move the stdlib (or parts of it) into site-packages, or pip needs to learn to handle a versioned stdlib. Cool.
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.
This boils down to whether we want to present the stdlib as a unified object tied to the Python release, or a set of modules no different from those on PyPI, that happen to be shipped with Python. I prefer the former view (it matches better how I think of "batteries included") whereas it looks like you prefer the latter (but don't see that as being in conflict with "batteries included"). Debating this in the abstract is probably not productive, so let's wait for a concrete PEP to thrash out details like this. Paul
On 06Jul2016 0753, Steve Dower wrote:
Thrashing out details should go on the workflow SIG, and I guess I'm the obvious candidate to push it asking. But given my own time constraints right now, I'm not going to dive into details if the high level concept (stdlib packages can be individually updated by end users apart from a full CPython release) is at issue.
Once there seems to be general agreement that this is a worthy goal, I'll see if I can put down details for how I would implement it. (And go join the core-workflow list, I guess :) )
Rather than wait for general agreement, since this thread is probably widely muted already, I'll put a PEP together to clearly set out what I'm envisioning here in a form we can directly discuss. But time is precious, so don't expect it this week :) (Also, on Brett's advice, this belongs on python-dev and not core-workflow right now.) Cheers, Steve
participants (2)
-
Paul Moore -
Steve Dower