On Sat, Jul 13, 2013 at 8:25 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> > On 13 Jul 2013 19:05, "Paul Moore" <p.f.mo...@gmail.com> wrote: > > > > On 13 July 2013 06:31, Nick Coghlan <ncogh...@gmail.com> wrote: > >> > >> * bundling a *full* copy of pip with the Python installers for Windows > and Mac OS X, but installing it to site-packages rather than to the > standard library directory. That way pip can be used to upgrade itself as > normal, rather than making it part of the standard library per se. This is > then closer to the "bundled application" model adopted for IDLE in PEP 434 > (we could, in fact, move to distributing idle the same way). > > > > > > How robust is the process of upgrading pip using itself? Specifically on > Windows, where these things typically seem less reliable. > > > > Personally, I have never upgraded pip using itself, because I only ever > install pip in virtualenvs, which don't have a lifespan as long as a pip > release cycle :-) It would be easy to imagine a new pip release resulting > in a *lot* of bugs raised against Python (rather than pip) saying that the > upgrade fails. And of course if an upgrade fails, we can't just release a > new version of pip that fixes the issue, because it's the *old* version > that is installed and has to do the upgrade. So there's manual fiddling to > do. Not a good experience for Python users. > > > > My current workflow is to have absolutely nothing installed in the > system Python and use virtualenvs for everything. This is a bit extreme, > but the issues I've hit in the past when package management has gone wrong > have made me very cautious. > > > > If the pip upgrade process is rock-solid, this isn't an issue, but I'm > not sure that it is, myself. > > I think we need to flip the dependencies so that pip as the installer has > all the essential code for installation from PyPI and then setuptools and > distlib depend on that pip infrastructure. No need to add anything to the > standard library prematurely when we can add it to pip instead. > +1 on the inversion. I don't know what that will do to pip, it makes sense to have the installer self-contained and the packaging/building libraries be something that you grab using the installer. Having to grab the packaging infrastructure to get an installer is the more painful route.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
