On 31 Aug 2013 02:02, "Paul Moore" <[email protected]> wrote: > > > On 30 August 2013 14:44, Donald Stufft <[email protected]> wrote: >> >> The Windows and OSX installers distributed by Python.org will automatically >> attempt to run ``python -m getpip`` by default however the ``make install`` >> and ``make altinstall`` commands of the source distribution will not. > > > Presumably the uninstaller components of these installers should similarly uninstall pip before uninstalling Python. Would something like a "python -m getpip uninstall" command be worthwhile to support this? (That's probably a question for the authors of the installers to answer, as I don't know if such a command would be needed - I suspect that the Windows MSI installer just records what files it installs and uninstalls them, so it may not be needed there). > > But otherwise +1 on this PEP.
Yeah, a command to uninstall pip and everything it installed would be desirable. I wouldn't consider it a *blocker* for inclusion (since anyone bootstrapping pip manually already has this problem), but it would be a nice one to solve (and having it on getpip neatly avoids the issues with pip uninstalling itself on Windows). For the other questions people asked: * yes, pyvenv should gain a "--without-pip" option * the only change to the existing get-pip.py bootstrap script should be to check for "getpip" and use it if available, and otherwise continue on with the legacy bootstrap mechanism. * I agree with Donald that getpip should be an ordinary standard library Python module * To allow releases to be recreated exactly from the source tarball, I agree with Donald that we need to actually include the relevant wheel files inside the CPython source tree. Retrieving them automatically at build time would be nice, but that unfortunately creates ugly version reproducibility issues, and also requires that the build process be patched before it can run on a trusted build server with no network access. * If we have to bundle setuptools as well, so be it. However, we should document that it is *not* guaranteed to be available, so projects that need it should declare the appropriate dependencies and mention "pip install setuptools" in the appropriate places to ensure it is available * a "--wheel-only" option for both getpip and pyvenv might be interesting, if pip gets to a point where it only needs setuptools for source builds and not installing from wheels. However, for now, I think the PEP should just assume setuptools will be bundled and installed as a pip dependency. I'm OK with that - Guido was amenable to adding setuptools to the standard library back in 2.5 as a case of practicality beating purity. (In retrospect, that would have just meant setuptools suffered from the same "can't readily be updated in existing Python versions" problem as distutils, so it's probably a net positive that PJE eventually decided not to continue with the idea) Cheers, Nick. > > Paul > > _______________________________________________ > Distutils-SIG maillist - [email protected] > http://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
