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

[Ian Bicking]

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.

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.

>> (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.  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).  So for now it's just always explicit, and if 
you want something else you have to set up your own shell scripts.

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org