[Distutils] Buildout status

[P.J. Eby]

At 10:29 AM 5/12/2011 -0400, Jim Fulton wrote:
>On Thu, May 12, 2011 at 10:09 AM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
>...
> >>> - stop adding features so distutils2/packaging slowly takes over
> >>
> >> Absolutely.  I couldn't agree more.  Just understand that we're going
> >> to have to support old packages that import setuptools in their setup
> >> scripts indefinitely.  That's one of the biggest challenges I see.
> >> Maybe packaging can (does?) provide a shim for this.
> >
> > As I said earlier, we do have backward compat in everything we do with
> > packages. That leads to ugly code in some places, but we have to.
> >
> > But as you said, there's the maturity problem...
>
>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.

You should be aware of a few things going forward, with respect to 
compatibility.  While Distribute includes many changes that are not 
in setuptools; the reverse is also true: setuptools includes bug 
fixes that are not currently fixed in Distribute.

One important fix is rather complex, as there was a problem with 
build-time dependency recursion that manifested itself as multiple 
bug reports for multiple packages.  This was fixed in setuptools, but 
the Distribute developers opted not to port the fix when it first 
came out a year or two ago, and AFAIK that has not changed.

So, you should be aware that you may have some non-trivial merge work 
ahead, if you want to include those fixes into Distribute.

In addition, Distribute contains various pieces of "anti-setuptools" 
code, in the sense that it deliberately attempts to prevent 
setuptools being installed or updated.  I don't know if you care 
about that one way or the other, but you should be aware that it exists.

(And of course, there is 2to3.)