[Distutils] Current status of PEP 439 (pip boostrapping)

[Lennart Regebro]

On Sat, Jul 13, 2013 at 8:07 AM, Donald Stufft <donald at stufft.io> wrote:
> +1 to this as well. Ideally, if we go down this route, installing python
> just comes with pip preinstalled. However that takes place :)

Well, I don't want a "however that takes place" that causes more
packaging problems in the future, so I'm -1 on that. :-)

I think including it in binary installers in such a way that pip can
upgrade itself is definitely a good idea. Including it in the source
code distributions seems less of a benefit. In fact, I don't even
think I want it as things stand right now.

Story time:

This week a lot of people had problems with zc.buildout, because of
the new releases of setuptools and distribute. Essentially they tried
to upgrade themselves and failed for various reasons, such as
distribute or setuptools being installed in the system python and not
being upgradeable, or not being upgradeable for other reasons, like
permissions.

Mostly, I had no problems, because the Python installs I use have only
one package installed: Virtualenv. That means that for most buildouts
I used, buildout had istelf installed setuptools or distribute in its
own isolated way. I only got errors where an overly complex build tool
insisted on making virtualenvs, installing distribute in them and then
running buildout with those virtualenvs. In those cases I had to run
bin/pip -U distribute, so it was also an easy fix.

So by default I prefer to have no packages except virtualenv for my
source-built Pythons.

This isn't a big issue, and I'm not gonna throw a hissyfit or
anything, but I think I'll -1 the idea of including pip in a source
install.


Having pyvenv install pip by default in the new environment is +lots
from me though.

Also, having pyvenv be able to install itself in a non-empty directory
would be great. ;-)

//Lennart