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 | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
