[Distutils] pip vs easy_install vs distutils2

Ian Bicking ianb at colorstudy.com
Tue Jun 1 05:12:17 CEST 2010


On Mon, May 31, 2010 at 10:11 AM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:

> On Mon, May 31, 2010 at 4:55 PM, Ian Bicking <ianb at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100531/08eaf837/attachment.html>


More information about the Distutils-SIG mailing list