On 18 July 2013 10:33, Vinay Sajip <vinay_sajip@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@gmail.com | Brisbane, Australia