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