Just on the zope in gae.
I have been hacking away at getting a core of zope running under gae.
(one example is http://baon.appspot.com/ which was a port of an old
portal_toolkit/cmf 1.0 site I used as an excercise)
I am currently using the following packages
app (completely gutted)
Though zope.proxy and zope.security have been pretty much gutted.
There is practically nothing in zope.app (basically some scaffold left
to support imports from other packages withouth having to change
I am also using
And had to write my own wrapper for pagetemplates to get closer to
and a gae specific publication (based on DefaultPublication) . I have
most of the parts (adapters and utilities) of the packages listed
above. I had to do that to avoid all of the extra dependancies pulled
in by the default zml that just won't work in gae (mainly
zope.security stuff) . For z3c.form I did end up using zcml (to hard
to do all the widgets by hand ;-) but had to remove all of the
permission directives from the class statements (like a said it's all
a bit of a hack at the moment)
It's not pretty ;-) but works.
I plan to revisit repose.bfg as a base for this work, but need to
remove cheetah and go back
to pure python zpt, and get rid of all the lxml depenancies.
I put all of this together manually so far (buildout comes next - now
that I know what I need to do).
One question before I go. I had to replace about 90% of
zope.security (well get rid of it)
what would be the best way of specifying a replacement for a core
package like zope.security rather than just replacing it.
If I wanted to share this work it would be a but confusing to call it
zope.security, and it is a bit much to monkey patch.?
Should I call it something like call it something like
z3c.gae.security and just tell people to install it in zope.security ?
On Thu, Apr 9, 2009 at 11:05 PM, Tobias Rodäbel <tobias.rodae...@mac.com> wrote:
> Shane Hathaway wrote:
> > Hanno Schlichting wrote:
> >> Wichert Akkerman wrote:
> >>> I'ld rather not see a whole slew of extra packagse appear. I also
> >>> how the extra number of packages and increasing size of sys.path
> >>> influence performance and restrictions on environments like GAE.
> >> For environments like GAE you don't want setuptools and its magic
> to be
> >> part of your application. This is were repackaging your entire app
> >> one zipped egg or some other flat structure comes in handy.
> >> Setuptools and eggs are a distribution format from my point of view.
> >> They are certainly not the best way to deploy your applications. The
> >> growing sys.path is affecting performance to some degree in all
> >> deployment environments.
> > Well, zc.buildout ought to be able to eliminate this concern for GAE
> > deployment. I haven't tried the recipe below, but it certainly seems
> > like the right idea.
> > http://pypi.python.org/pypi/rod.recipe.appengine
> I released a new version today. It's a lot easier now to use several
> eggs within gae. This test thingy http://zpttest.appspot.com/ uses
> zope.interface and zope.pagetemplate plus their dependencies. I'm
> planning to release another sample project maybe during easter
> holidays. It's much more fun since you zope people cleaned up a lot of
> dependencies and unveiled zc.buildout. Thanks!
> Zope-Dev maillist - zope-...@zope.org
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -