On Sun, May 30, 2010 at 12:13 PM, Carl Meyer <c...@oddbird.net> wrote:
> I sympathize with the ease-of-use reasons for having something in the > stdlib. And I'm not sure putting pip in the stdlib would be good for > pip's development. > This is my primary concern. I have no problem with merging pip with distutils2, so that pip can share utility code, etc. While it would still have to be backward compatible with old packages, I don't think that would have to change just because it merged with distutils2. But... the standard library is where I get stuck. And release cycles. pip has its own release cycle right now. It's not particularly formal, but it's a fairly regular release schedule. In terms of scope I don't think pip is finished. For instance, at least pip should have querying abilities (similar to what yolk does). Also the standard library's backward compatibility guarantee's don't seem as relevant to an installer -- an installer is something you run at a certain point in time, it's not part of the runtime of a system itself, and so changes are not as much of a problem. At the same time it has to be compatible with packages written a long time ago... but it's a different sort of compatibility. 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, if that's not the case, then we need to figure what it means to have distutils2 "in" the standard library while still making regular releases. If Python shipped a "install distutils2" script then that I could work with, because it would imply distutils2 was blessed (and whatever the version at the time of release was, it could possibly be installed) but without attaching release cycles. -- Ian Bicking | http://blog.ianbicking.org
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
