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

[Jim Fulton]

Martin Aspeli wrote:
> 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.

As I mentioned before, this is already supported:

   [buildout]
   parts = ... foo ...

   [foo]
   recipe=zc.recipe.egg
   eggs = egg1 egg2 ...
   interpreter = mypy

After running the buildout, you will have bin/mypy.

If you run bin/mypy, then you'll get a Python prompt and you can import
and use anything provided by the listed eggs and their dependencies.

You can also do:

   bin/mypy somescript args

and run the script somescript with the given arguments and it
will have the path set up for it.

One wart is that any scripts defined by the eggs will be installed
too when you run the buildout, which you may or may not want. There's
a way to suppress this but I should probably add a dedicated interpreter
recipe that just creates an interpreter.


> 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

Yes, depending on how complex Pylon's setup was.  For example, if Pylons
exposed it's scripts using setuptools entrypoints, you you could install
them with buildout.

> (in the same way, the z2c.recipe.zope2instance recipe 
> knows about how the zopectl and runzope scripts set their PYTHONPATH and 
> patches them).

Zope startup scripts are sort of interesting because they
are instance specific -- combining instance-specific configuration
with software definition.  This is something that setuptools
entry points don't handle very will by themselves.  That's
why buildout has custom script generation facilities that alllow
definition of extra initialization code and entry point arguments.

I wouldn't be surprised if Pylons had similar needs.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org