On Fri, Jul 12, 2013 at 4:35 AM, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
Donald Stufft <donald <at> stufft.io> writes:

> We should remember that in general people have considered PyEnv that ships
> with Python 3.3 an inferior alternative to virtualenv largely in part
> because they have to fetch setuptools and pip prior to using it whereas in
> virtualenv they do not.

Let's remember, that's a consequence of packaging being pulled from 3.3 - the
original plan was to have the ability to install stuff in venvs without third-
party software being necessary.

I think it's also a consequence of having to remember how to install pip. I don't have the get-pip.py URL memorized in order to pass it to curl to download for executing. At least with Nick's suggestion there is nothing more to remember than to run getpip right after you create your venv.

It's also a consequence of habit and laziness, both of which programmers are notorious about holding on two with both hands as tightly as possible. =)


There is no real barrier to using setuptools/pip with Python 3.3+ venvs: For
example, I published the pyvenvex.py script which creates venvs and installs
setuptools and pip in a single step:


Admittedly it's "only a Gist" and not especially publicised to the wider
community, but that could be addressed.

The example in the venv docs actually does something similar but with distribute and pip: http://docs.python.org/3.4/library/venv.html#an-example-of-extending-envbuilder. I have filed a bug to update it to setuptools: http://bugs.python.org/issue18434 .
The current situation, as I see it, is a transitional one. When distlib-like
functionality becomes available in the stdlib, other approaches will be
possible, which improve upon what's possible with setuptools and pip. I've
demonstrated some of this using distil. When targeting Python 3.4, shouldn't
we be looking further than just advancing the status quo a little bit?

It's been said numerous times that "executable setup.py" must go. ISTM that,
notwithstanding "practicality beats purity", a pip bootstrap in Python
would bless executable setup.py and help to extend its lifespan.

I don't think that analogy is quite fair. It's not like setup.py either runs something if it's installed OR installs it and then continues execution. Having installation code execute arbitrary code is not a good thing, but executing code as part of executing an app make sense. =) But I do see the point you're trying to make.

I'm personally +0 on the explicit install and +1 on the implicit bootstrap. I'm fine with adding a --no-bootstrap option that prevents the implicit install if people want to block it, or even prompting by default if people want to install and have a --bootstrap option for those that want to happen automatically for script usage. If this were a library we are talking about then I would feel differently, but since this is an app I don't feel bad about it. Then again as long at the getpip script simply exits quietly if pip is already installed then that's not a big thing either.