[Distutils] [buildout] RFC: buildout support for distribute

[P.J. Eby]

At 10:27 PM 10/13/2009 +0200, Tarek Ziadé wrote:
>On Tue, Oct 13, 2009 at 10:07 PM, P.J. Eby <pje at telecommunity.com> wrote:
> >> Ok sure, makes sense. We will return 'distribute' only if 'setuptools'
> >> is from the 0.6.x series
> >> and below.
> >
> > Great.  I assume that means you plan to incorporate any further bug fixes
> > that land in 0.6c10 (or, gods forbid, c11) in the release where this change
> > is made.
>
>Yes, as long as we are able to spot them in your commits / issue
>trackers changes.
>
>The latest commit you've made in setuptools package is still cryptic
>to us because
>it fixes many things at once.

Sorry about that, but it was pretty much the only way to get it done 
in a weekend, without the overheads of separate commit messages, doc 
changes, and backporting killing me.  Those overheads were the main 
reason I wasn't making changes more often; I dreaded the amount of 
work involved.

Also, as it happened, I was able to fix multiple problems with single 
changes this way.

>We were able to backport the sandbox violation but that's it at this point.

The __getstate__/__setstate__ stuff in pkg_resources is also sandbox 
support; it makes it possible to keep working_set changes by 
recursive builds from corrupting the parent build's working set.  I 
also expect it to support a "reset pkg_resources" API in 0.7a1 -- a 
long-requested feature.


> > For versions you don't support emulating, I strongly suggest 
> adding an error
> > of some kind, since actually *installing* setuptools with Distribute still
> > present on sys.path would cause a problem.
>
>It is still unclear to me where this exception has to be thrown 
>since some APIs
>in WorkingSet can be used just to check things out.
>
>I am guessing WorkingSet.resolve and parse_requirements are enough, but that's
>just from the zc.buildout use case.

One thing you could possibly do is capture Distribution.insert_on(), 
which would allow you to detect that setuptools is about to be added 
to a working set.

Still another is that you could install a distribute.pth that puts 
Distribute on the path first, since 'distribute.pth' is 
alphabetically before 'easy-install.pth' and 'setuptools.pth'.

(I'm not suggesting these are complete or risk-free solutions, of course.)