2011/5/12 Kelsey Hightower <[email protected]>: >> OK, given the discussion, I guess the easiest course for buildout would be >> for buildout 2 to support just distribute next (to simplify the code) >> and then work >> on transitioning to packaging. Buildout 1 would largely stay as it is with >> bug >> fixes. > > Tarek, correct me if I am wrong here, but 3rd party tools will need to > rely on distribute(setuptools) as packaging/d2 will never provide a > backwards compatible substitute or API. Packaging/d2 relies on > distribute as an external dependency. > > So in this case buildout2 will need to support distribute and later > add support for packaging down the road. > > So buildout2 will need packaging/d2 + distribute.
There are three concerns: 1 - tools used by zc.buildout itself to manage packages. 2 - what's imported in setup.py in every project 3 - the project's dependencies for 1, packaging only can be used in the long term since we provide backward compat. for 2, if "setuptools" is imported there, it's required of course. same for 3. Now for how packaging installs setuptools-based project, it's dealt at our level. IOW, zc.buildout in the long term will only have to deal with the packaging APIS and not worry about what we do internally. Practically speaking, What's not clear yet is how we will inform that we need that extra Distribute dependency. Last, for 2 and 3, if the project uses some APIs that are supposed to see all installed packages for example, it'll have to use Distribute once it has added the PEP forward compat layer (unless Setuptools also adds it, so both will work) I hope this is clear :) Cheers Tarek -- Tarek Ziadé | http://ziade.org _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
