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.
Martin
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
