[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like

Martin Aspeli optilude at gmx.net
Sun Jan 28 15:55:22 EST 2007

Jim Fulton wrote:

> The first step to compatibility is deciding what it means. :)
> I'm all in favor of workingenv/buildout compatibility.
> I'd like to see some specifics of how people would like
> to use workingenv amd buildout together.  I have some guesses,
> but I'd rather hear people say what they want to do.
> I think this would be much more useful than a discussion
> of implementation details at this point.  Once we know what
> we want the end result to be, I'm sure you and I can work out
> some implementation that makes sense.

I agree, and I find myself a bit confused by this orientation as well.

The main use case I could imagine wanting to solve would be that I'd 
like to run 'python' inside zc.buildout and have an interactive prompt 
that had all the eggs that zc.buildout knew about available. That is, 
I'd like to be able to do "from zope.interface import ..." and so on.

Similarly, say I had two applications, one in Zope and one in Pylons, 
part of the same deployment (possibly interwoven using wsgi). If I 
installed elementtree as an egg in buildout.cfg, I'd expect it to be 
available to both. If that means patching some of pylon's confg files or 
startup scripts to explicitly reference eggs that buildout is managing, 
it would mean that I'd need a very specific recipe for Pylons 
development that would need to know a lot of detail about how that sets 
up its environment (in the same way, the z2c.recipe.zope2instance recipe 
knows about how the zopectl and runzope scripts set their PYTHONPATH and 
patches them).

In both these cases, I wouldn't care much about workingenv per se, only 
that I had a sensible way of managing this environment.


More information about the Zope-Dev mailing list