On Mon, Jun 7, 2010 at 1:14 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Mon, 7 Jun 2010 11:35:16 -0500
Ian Bicking <ianb@colorstudy.com> wrote:
>
> I think there is a general consensus that functionality should not be tied
> to a Python release, but the results are ad hoc.

I disagree with this. Tying new functionality to a Python release
vastly simplifies dependency management (instead of having to track the
versions of N external libraries, sometimes with inter-dependencies).

I say there is consensus because as far as I know anything substantial has a maintained version outside the standard library; argparse is implicitly, unittest is unittest2, ElementTree always has maintained a separate existence, simplejson implicitly.

> (Most specifically without serious
> thought about this development process I am pessimistic about an
> orderly or positive inclusion of distutils2 in packaging workflows.)

Without any discussion of specifics, I find it hard to understand what
you are concerned about.

1. How will distutils2 updates be made available between Python releases?
2. How will distutils2 features be made available in older Python releases?
3. How will old standard library releases of distutils2 be managed?  E.g., if pip starts using distutils2, at the time distutils2 ends up in the standard library there is a version of distutils2 I cannot simply reject as incompatible, meaning I can't make use of any new features or bug fixes.

--
Ian Bicking  |  http://blog.ianbicking.org