[Zope-dev] Re: ploneout - Or how using zc.buildout for a common
Zope2 project might look like
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
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