On Mon, May 31, 2010 at 4:55 PM, Ian Bicking <i...@colorstudy.com> wrote: [..] > Well, I could list the problems, but basically I strongly dislike the idea > that, say, Python 3.2 will ship distutils2 with a certain version of pip, > and that people would have to upgrade Python or wait for a Python release to > get upgrades of pip.
.. or allow people to configure in distutils2 an alternative installer. That is: a newer version of Pip. So they don't suffer from the Python release cycle by being able to upgrade the installer. I don't think being able to upgrade the installer from within the stdlib breaks the stdlib stability promise, since an installer is not something people use in their code as a library. It doesn't really suffer from API deprecation: it's a high-level end-user tool that people use to install stuff. It's interface (that is, the command line options I guess) can be quite stable. If people are using some packaging API in their code, I'd expect them to be in the Distutils2 'toolbox' part, which can benefit from the stdlib stability. Then Pip-the-installer could rely on it, and maybe improve those API by having its own version for a while until the next Python version is released. Python would ship with a version of the installer that can be upgraded by people that know what they do. Tarek -- Tarek Ziadé | http://ziade.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
