On Jul 17, 2013, at 8:03 PM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
> Leaving aside specialised corporate setups with no access to PyPI, any > installer is of very limited use without a reliable network connection. Most > of the people we're expecting to reach with these changes will have always on > network connections, or as near as makes no difference. However, pip and > setuptools will change over time, and "-m getpip" allows upgrades to be done > fairly easily, under user control. So ISTM we're really talking about an > initial "python -m getpip" before lots and lots of "pip install this", "pip > install that" etc. It's hardly true that this is only specialized corporate setups. Another situation off the top of my head would be at various meet ups or conferences where people are trying to teach new people and might have little or no access. Even assuming they *do* have access to the network, accessing the network includes a number of extra failure conditions. For instance pip 1.3+ is the first version of pip to include verification of SSL and we've had a fair number of people need help making pip be able to reach PyPI through their particular setups. Sometimes it's because the version of OpenSSL is old, other times they don't have OpenSSL at all, or they have a proxy between them and PyPI which is preventing them or requires additional configuration to make it work. Each possible failure condition is another thing that can go wrong for users, each one is another point of frustration and another reason not to fetch it if it can be helped. You state that an installer is of limited use without a network connection but that's not particularly true either. Especially with Wheels and the removal of the simple "setup.py install" and the current focus on having a local cache of pre-built wheels I suspect there to be a decent number of people wanting to install from local wheels. It is true that each problem has a solution, but they are different solutions for each problem and generally require that the person be aware of the problem and the solution prior to having it in order to work around it. > > Did you (or anyone else) look at my getpip.py? In what way might it not be > fit > for purpose as a bootrstapper? If it can be readily modified to do what's > needed (and I'll put in the work if I can), then given that bootstrapping was > the original impetus lacking only an implementation which passed the "simple > enough to explain, so a good idea" criterion, perhaps that situation can be > rectified. I did not look at your getpip.py. I've always believed that an explicit "fetch pip" step was not a reasonable step in the process. However bootstrapping had an implementation it's major issue was that it was implicit and that was deemed inappropriate. If you post it again I'll review it but I'll also be against actually using it. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
