On Sun, May 30, 2010 at 7:13 PM, Carl Meyer <[email protected]> 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. So I don't have a solution to propose. But I have a > hard time believing that reimplementing pip is even under serious > consideration. It smells of seriously underestimating the amount of work > involved.
I won't speak for others, but on my side, I don't underestimate the amount of work involved in an installer (heck, if I was scared by the amount of work in packaging, I'd quit 2 years ago ;)), but rather trying to figure out what is the path for a better packaging ecosystem. (it's a bit of a wicked problem) If you put aside the backward compatibility issues for a moment, I see several problems right now: A - If distutils2 doesn't include an installer, a fresh Python install will not be fully functional. I don't think it's the best option. Python should provide an installer/uninstaller that is compatible with the latest standards distutils2 provides. I don't want to release a software that will have to rely on a third party installer which don't exists yet : there's no clear plan to support the new standards yet in pip or in any other project afaik. B - adding within distutils2 an installer like pip (with the support of new standards) at a given version doesn't mean you can't develop the next version and release it as a third party package, so people can upgrade their installer and get the bleeding edge thing. This is doable as long as the installer is configurable. C - easy_install for instance, is already installed in Mac OS X by default. That makes sense from a end-user pov. So why wouldn't we have an installer in distutils2 in the stdlib ? D - letting *each* distribution decide what installer will be used when "python setup.py install" is called, without letting the end-user decides, (that's the ez_setup embed thing) means that we bury our goal to get rid of this file and to move toward statically defined metadata+ content. IOW have a clean separation between a Distribution and the code that is used to install it (eg the installer). Now about the backward compatibility issues: - as discussed with Ian, we are going to add backward compatibility in pkgutil, so we can read old egg-info formats. IOW, it deprecates the usage of pkg_resources in favor of an unified API. - if the installer part of distutils2 includes backward compatibility, it's ok I guess, as long as it's isolated to that part. So, I am still proposing to merge both projects and to have two kinds of releases: - distutils2 + pip included (maybe a renamed script) - pip, alone. And with the new metadata we have "provides-dist", so we can avoid conflicts here. Regards, Tarek -- Tarek Ziadé | http://ziade.org _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
