several zope.* libs within gae (was ZCML implementations: where should they go)
Hi, Shane Hathaway wrote:
Hanno Schlichting wrote:
Wichert Akkerman wrote:
I'ld rather not see a whole slew of extra packagse appear. I also wonder 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 into 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.
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! Cheers, Tobias
Hi 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) component configuration contenttype datetime deferredimport deprecation event exceptions i18n i18nmessageid interface lifecycleevent location pagetemplate proxy publisher schema security tal tales testing traversing 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 packages) I am also using peak.util z3c.form And had to write my own wrapper for pagetemplates to get closer to zope.app.pagetemplate and a gae specific publication (based on DefaultPublication) . I have manually registered 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 ? Tim On Thu, Apr 9, 2009 at 11:05 PM, Tobias Rodäbel <tobias.rodaebel@mac.com> wrote:
Hi,
Shane Hathaway wrote: > Hanno Schlichting wrote: >> Wichert Akkerman wrote: >>> I'ld rather not see a whole slew of extra packagse appear. I also wonder >>> 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 into >> 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!
Cheers, Tobias _______________________________________________ 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 )
Hey there, Tim Hoffman wrote: [snip]
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 ?
This is an interesting question. Would it be possible to make changes in zope.security itself so that there's is a "do-nothing" Python version available when you install it on GAE? zope.security is a bit like middleware in that much of your app will continue to work if you don't use it. We could simply recognize this in zope.security and have a mode for it so it doesn't actually create security proxies. Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tobias Rodäbel wrote:
Hi,
Shane Hathaway wrote:
Hanno Schlichting wrote:
Wichert Akkerman wrote:
I'ld rather not see a whole slew of extra packagse appear. I also wonder 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 into 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.
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!
Cool! You should be able to use zope.component there in its latest incarnation, too: the C bits are all optional at this point. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3hcU+gerLs4ltQ4RAuG5AKCMROgDfhLcckXqNmznfEZCrolHkACgh1ua PR4pPE5Df80kGcg9RWkG0yw= =gTQ9 -----END PGP SIGNATURE-----
participants (4)
-
Martijn Faassen -
Tim Hoffman -
Tobias Rodäbel -
Tres Seaver