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

[Jim Fulton]

On Jan 29, 2007, at 2:25 PM, Ian Bicking wrote:

> Jim Fulton wrote:
>>> 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.
>
> Pylon's doesn't have its own scripts.  Generally an application  
> will require Pylons, Pylons requires PasteScript, and PasteScript  
> provides a paster script.  A quirk in buildout was that asking for  
> the paster script to go in bin/ didn't seem to work unless I  
> specifically was installing PasteScript.  Anyway, they all use  
> entry points, so that part is fine.

Right. The eggs recipe only installs scripts for the named eggs, not  
for dependencies.

> I've considered encouraging each WSGI/PasteDeploy application to  
> ship its own script that hides the existence of paster (or any  
> specific framework).  But that doesn't seem quite right either,  
> since a WSGI application can be (and in production usually is) used  
> as a library in addition to a stand-alone application.  At that  
> point it becomes similar to a Zope product, or Plone content type,  
> or... well, I guess there's limits to the similarity as I try to  
> find analogs.  I guess that's the style differences between Zope  
> and... all the other frameworks.  I'm not sure what name really  
> describes the difference in pattern.

I think I do. :)

Traditionally, Zope was a pluggable *application*, rather than a  
library.  Typically eggs are meant to be used as libraries.

We're moving in the direction of having most of Zope available as  
eggs that can be used as libraries.  Zope 3 is already being widely  
used that way.

In the future there will still be pluggable applications (e.g. Plone)  
built on libraries provided by the Zope, Plone, and other projects.


>>> (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.
>
> You just have to give the config file as an argument when you start  
> the server, there's nothing setup that binds a script with a config  
> file.

Right. And for convenience, you often want that.

>   I played with a #! setup where the config file became a script,  
> but I found it rather hard to work with (there's a lot of problems  
> with how #! works across platforms).

yup

> So for now it's just always explicit, and if you want something  
> else you have to set up your own shell scripts.

I think that in practice, you'll want to automate this.  At least we  
did.  In many cases, you can avoid generating shell scripts and  
generate Python scripts instead.  I like this much better and the  
techniques that Phillip Eby worked  out can be used to make this work  
nicely on both Unix-based systems and Windows.

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