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:

* 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.

--