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.