[Distutils] PEP 439 and pip bootstrap updated

Nick Coghlan ncoghlan at gmail.com
Fri Jul 12 07:11:14 CEST 2013


On 12 July 2013 12:12, Richard Jones <richard at python.org> wrote:

> The point of PEP 439 is that the current situation of "but first do
> this" for any given 3rd-party package installation was a bad thing and
> we desire to move away from it. The PEP therefore proposes to allow
> "just do this" to eventually become the narrative. The direction this
> conversation is heading is removing that very significant primary
> benefit, and I'm not convinced there's any point to the PEP in that
> case.
>

That was never the primary benefit to my mind. The status quo sucks because
there is *no* simple answer to "first, do this", not because some kind of
bootstrapping is needed.
The problem in my view is that the "first, do this" step is currently a
mess of various arcane platform dependendent incantations that may or may
not work (and may even contradict each other) and can't be readily
incorporated into an automatic script because they're not idempotent.

Accordingly, I consider simplifying that "first, do this" step to "python
-m getpip" to be a major upgrade from the status quo:

* unlike curl, wget and "python -c" incantations, it's immediately obvious
to a reader what it is supposed to do: "Get pip"
* unlike curl, wget and "python -c" incantations, it can be easily made
platform independent
* unlike curl, wget and "python -c" incantations, it can be easily made
idempotent (so it does nothing if it has already been run)
* through "getpip.bootstrap" it will provide the infrastructure to easily
add automatic bootstrapping to other tools

In particular, it establishes the infrastructure to have pyvenv
automatically bootstrap the installer into each venv, even when it isn't
installed system wide (which is the key missing feature of pyvenv relative
to virtualenv).

Having the retrieval of pip happen automagically as part of an install
command initially sounded nice, but I'm now a firm -1 on that because
making it work cleanly in a cross-platform way that doesn't conflict with a
manual pip install has proven to require several awkward compromises that
make it an ugly solution:

* we have to introduce a new install command (pip3 vs pip) to avoid
packaging problems on Linux distros
* this is then inconsistent with Windows (which doesn't have separate
versioning for the Python 3 installation)
* we have to introduce new bootstrap arguments to pip
* we have to special case installation of pip and its dependencies to avoid
odd looking warning messages
* the implementation is tricky to explain
* it doesn't work nicely with the "py" launcher on Windows (or equivalents
that may be added to other platforms)

If your reaction is "well, in that case, I don't want to write it anymore",
I will be disappointed, but that won't stop me from rejecting this approach
and waiting for someone else to volunteer to write the more explicit
version based on your existing bootstrap code. I'd prefer not to do that
though - I'd prefer it if I can persuade you that "python -m getpip" *is* a
major upgrade over the status quo that is worth implementing, and one that
adheres to the Zen of Python, in particular:

* Explicit is better than implicit
* Simple is better than complex
* Readability counts
* Errors should never pass silently, unless explicitly silenced
* In the face of ambiguity, refuse the temptation to guess
* If the implementation is hard to explain, it's a bad idea.
* If the implementation is easy to explain, it may be a good idea.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130712/cf1a5268/attachment-0001.html>


More information about the Distutils-SIG mailing list