On Mon, May 31, 2010 at 10:11 AM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
On Mon, May 31, 2010 at 4:55 PM, Ian Bicking <ianb@colorstudy.com> wrote:
[..]
> Well, I could list the problems, but basically I strongly dislike the idea
> that, say, Python 3.2 will ship distutils2 with a certain version of pip,
> and that people would have to upgrade Python or wait for a Python release to
> get upgrades of pip.

.. or allow people to configure in distutils2 an alternative
installer. That is: a newer version of Pip.
So they don't suffer from the Python release cycle by being able to
upgrade the installer.

The biggest advantage I see of directly merging pip and distutils2 is that they could share code... but if you can upgrade pip without distutils2 then pip will have to work around any bugs in distutils2 to maintain compatibility with old versions of distutils2 (assuming it supports upgrading *only* pip).  At which point they aren't "merged" at all, and pip is exactly where it is now.

If distutils2 *and* pip were upgrading together consistently (i.e., they were actually merged), and if releases were essentially a superset of both projects' releases, then I'd have no problem with that.  I think we can offer *some* backward compatibility guarantees for pip, like command-line interface (but not for any internal interfaces at this time, though maybe some in the future).

In terms of release cycles I'm also somewhat uncomfortable with the extraction of the VCS support... it feels more like a political concession than a good technical decision.  I don't want the brokenness of the stdlib process to drive choices in pip.  I also don't think it should drive choices in distutils2, and I don't think it's healthy for distutils2, but it's not my project so I'll only offer that as advice.

I strongly support the addition of a new category of library that is somewhere between the standard library and just-another-library, a library with some authority and support in the community, but with a separate release cycle entirely.  There's a lot of libraries that should be like this, but it's not too painful because most of them are pretty much "done" -- they've had very few changes or additions (maybe for good reasons, maybe not).  I think distutils/setuptools/distutils2/pip reveal the need for this category more than many packages because they are both important and need community approval, but are very much Not Done and I think will probably never be done (since they interact with so many moving parts some of which aren't part of Python at all).

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