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).


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:[EMAIL PROTECTED]                Python 
CTO                             (540) 361-1714                  
Zope Corporation        http://www.zope.com             http://www.zope.org

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to