[Distutils] PEP 439 and pip bootstrap updated

[Brett Cannon]

On Fri, Jul 12, 2013 at 4:35 AM, Vinay Sajip <vinay_sajip at 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:
>
> https://gist.github.com/vsajip/4673395
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130712/d97db68c/attachment.html>