[Zope-dev] Re: ploneout - Or how using zc.buildout for a common
Zope2 project might look like
jim at zope.com
Mon Jan 29 14:53:00 EST 2007
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
>> exposed it's scripts using setuptools entrypoints, you you could
>> 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
> 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
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).
> 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 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
More information about the Zope-Dev