[Distutils] Buildout status

Tarek Ziadé ziade.tarek at gmail.com
Thu May 12 21:19:31 CEST 2011


2011/5/12 Kelsey Hightower <kelsey.hightower at gmail.com>:
>> 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


More information about the Distutils-SIG mailing list