[Distutils] Q about best practices now (or near future)

[Nick Coghlan]

On 18 July 2013 10:33, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> Nick Coghlan <ncoghlan <at> gmail.com> writes:
> More importantly, it doesn't seem like the PEP process has been followed, as
> other proposed alternatives (I mean the approach of "python -m getpip", as
> well as my specific suggested getpip.py) have not received adequate review
> or obvious negative feedback, nor have the pros and cons of bootstrapping
> vs. bundling been presented coherently and then pronounced upon.

Then (help) write the missing PEP! PEP's don't appear out of nowhere,
they happen because people write them. That's why I sent a request to
the list explicitly asking for someone to write a competitor to PEP
439 *because* I wasn't going to accept it, so we need something else
to champion one or more of the alternatives. So far, Paul Nasrat is
the only person who offered to take on that task, and he has yet to
respond to my acceptance of that offer (which I'm not reading too much
into at this point - I only sent that reply a day or two ago, and I
expect that like the rest of us, Paul has plenty of other things to be
working on in addition to Python packaging).

There are only two approaches that are completely out of the running
at this point:

* implicit bootstrapping of pip at first use (as PEP 439 proposed)
* promoting anything other than pip as the default installer

Various other options for "how do we make it easier for end users to
get started with pip" are all still technically on the table,
including:

* explicit command line based bootstrapping of pip by end users (just
slightly cleaned up from the status quo)
* creating Windows and Mac OS X installers for pip (since using
wget/curl to run a script is either not possible or just an entirely
strange notion there and forms a major part of the bootstrapping
problem - after all, we expect people to be able to use the CPython
Windows and Mac OS X installers just fine, why should they have any
more trouble with an installer for pip?)
* implicit bootstrapping of pip by the CPython Windows and Mac OS X installers
* implicit bootstrapping of pip by the Python Launcher for Windows
* bundling pip with the CPython Windows and Mac OS X installers (and
using it to upgrade itself)
* bundling pip with the Python Launcher for Windows (and using it to
upgrade itself)

Yes, I have my opinions and will try to nudge things in particular
directions that I think are better, but until someone sits down and
*actually writes the PEP for it*, I won't know how justified those
opinions are. Even though I have already stated my dislike for some of
these approaches (up to and including misstating that dislike as "not
going to happen"), that just means the arguments in favour would need
to be a bit more persuasive to convince me I am wrong.

The problem statement also needs to be updated to cover the use case
of an instructor running a class and wanting to offer a local PyPI
server (or other cache) without a reliable network connection to the
outside world, since *that* is the main argument against the
bootstrapping based solutions.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia