zope.pagetemplate new install dependencies introduced since 3.5.0 and a modest proposal.
Hi I have been using zope.pagetemplate for quite some time within repoze.bfg projects and bobo (+zope.component) on google appengine (python 2.5.x). I have just been doing some upgrades etc... and discovered that zope.pagetemplate in 3.5.2 has introduced a whole heap of new dependancies. In 3.5.0 non testing install requirements where setuptools zope.interface zope.tales zope.tal where as 3.5.2 install requires setuptools zope.interface zope.component zope.security [untrustedpython] zope.tales zope.tal zope.i18n zope.i18nmessageid zope.traversing Now I already had i18n, i18nmessageid and zope.component, zope.interface as I was already using them, but now zope.security and zope.traversing means I also now get zope.browser-1.3-py2.5.egg zope.contenttype-3.5.1-py2.5.egg zope.exceptions-3.6.1-py2.5.egg zope.location-3.9.0-py2.5.egg zope.publisher-3.12.4-py2.5.egg zope.security-3.7.3-py2.5-linux-x86_64.egg zope.traversing-3.13-py2.5.egg zope.proxy-3.6.1-py2.5-linux-x86_64.egg I know that zope.pagetemplate.engine actually had a dependency on zope.traversing but this was never expressed in the EGG-INFO/requires.txt in 3.5.0. I used my own engine given I always running trusted code. (I am using metal as well). So now for my modest proposal, do you think it would be feasible to move the restricted engine implementations out of zope.pagetemplate.engine and into some higher level package and provide a simple trusted engine that anyone can use (that supports metal as well) As the architecture.txt for zope.pagetemplate says - An *expression engine* is responsible for compiling expressions and for creating expression execution contexts. It is common for applications to override expression engines to provide custom expression support or to change the way expressions are implemented. The `zope.app.pagetemplate` package uses this to implement trusted and untrusted evaluation; a different engine is used for each, with different implementations of the same type of expressions. So maybe the best place for the full expression engines would be zope.app.pagetemplate. This would seem to be in keeping with a lot of the work, breaking down core zope technologies into re-usable (outside of a pure zope stack) components. This would in theory bring the dependencies back down to zope.interface zope.tales zope.tal zope.i18n zope.i18nmessageid If people think this is a good idea, I am quite willing work on this (with guidance ;-), so thoughts, comments welcome. TIA Tim Hoffman
Hi. On Thu, Aug 12, 2010 at 7:36 AM, Tim Hoffman <zutesmog@gmail.com> wrote:
I have been using zope.pagetemplate for quite some time within repoze.bfg projects and bobo (+zope.component) on google appengine (python 2.5.x).
Is there a reason why you don't use Chameleon? Since version 1.1 it should be fully compatible with GAE. It might be easier to switch to the new kid, instead of trying to make the highly integrated zope.pagetemplate work for you.
So now for my modest proposal, do you think it would be feasible to move the restricted engine implementations out of zope.pagetemplate.engine and into some higher level package and provide a simple trusted engine that anyone can use (that supports metal as well)
At least Zope2 depends on this engine, so moving the engine out into a zope.app.* package is not an option, it would have to be some new zope.* package. I'm not sure what and how BlueBream and Grok use this.
If people think this is a good idea, I am quite willing work on this (with guidance ;-), so thoughts, comments welcome.
I'd like to hear the reasons for not using Chameleon. To me that looks like the better forward path and avoid lots of adjustments and a lengthy migration period for zope.pagetemplate users. Hanno
Hi On Thu, Aug 12, 2010 at 4:19 PM, Hanno Schlichting <hanno@hannosch.eu>wrote:
Hi.
On Thu, Aug 12, 2010 at 7:36 AM, Tim Hoffman <zutesmog@gmail.com> wrote:
I have been using zope.pagetemplate for quite some time within repoze.bfg projects and bobo (+zope.component) on google appengine (python 2.5.x).
Is there a reason why you don't use Chameleon? Since version 1.1 it should be fully compatible with GAE.
We have a large code base using zope.pagetemplate on appengine, and when we started chameleon couldn't run on appengine. I should spend some time checking out how well chameleon runs now. Though I have some discussion recently on a few descrepancies in behaviour.
It might be easier to switch to the new kid, instead of trying to make the highly integrated zope.pagetemplate work for you.
Its already been working since very early 2009 so it's more about being able to setup buildout etc..... rather than hand crafting everything.
So now for my modest proposal, do you think it would be feasible to move the restricted engine implementations out of zope.pagetemplate.engine and into some higher level package and provide a simple trusted engine that anyone can use (that supports metal as well)
At least Zope2 depends on this engine, so moving the engine out into a zope.app.* package is not an option, it would have to be some new zope.* package. I'm not sure what and how BlueBream and Grok use this.
Bummer didn't realize this
If people think this is a good idea, I am quite willing work on this (with guidance ;-), so thoughts, comments welcome.
I'd like to hear the reasons for not using Chameleon. To me that looks like the better forward path and avoid lots of adjustments and a lengthy migration period for zope.pagetemplate users.
I will revisit chameleon. One thing I note that chameleon uses python as default expressions where as zope.pagetemplate (and all our code) uses tal expressions as default, and "python:" when we want python. If that default behaviour can't easily be changed (I can't find anything in the docs on this) it would mean a lot of rework, in just 2 projects we have over 500 different .pt files ( sure some global search and replaces will help, but still a lot of changes and testing. So at this point chameleon needs to be api/implementation compatible with zope.pagetemplates (metal included) or its a big job shifting. Hey it was just a suggestion and if people think zope.pagetemplate is a bit of a dead end, then maybe I should invest the time on chameleon Rgds T Hanno
Hi Hanno Actually went back and had a look at my appengine instances, and the earliest one using zope.pagetemplate has been running since Aug, 2008 ;-) T
It might be easier to switch to the new kid, instead of trying to make the highly integrated zope.pagetemplate work for you.
Its already been working since very early 2009 so it's more about being able to setup buildout etc..... rather than hand crafting everything.
So now for my modest proposal, do you think it would be feasible to move the restricted engine implementations out of zope.pagetemplate.engine and into some higher level package and provide a simple trusted engine that anyone can use (that supports metal as well)
At least Zope2 depends on this engine, so moving the engine out into a zope.app.* package is not an option, it would have to be some new
On Thu, Aug 12, 2010 at 10:46 AM, Tim Hoffman <zutesmog@gmail.com> wrote:
I will revisit chameleon. One thing I note that chameleon uses python as default expressions where as zope.pagetemplate (and all our code) uses tal expressions as default, and "python:" when we want python. If that default behaviour can't easily be changed (I can't find anything in the docs on this) it would mean a lot of rework, in just 2 projects we have over 500 different .pt files ( sure some global search and replaces will help, but still a lot of changes and testing.
Changing the default expression is easy. z3c.pt does exactly that to keep compatibility with zope.tal.
So at this point chameleon needs to be api/implementation compatible with zope.pagetemplates (metal included) or its a big job shifting.
It is 99% compatibile. The only real difference is, that it requires all your templates to be valid XHTML. Otherwise almost all of Zope2/Plone with all kinds of weird code works.
Hey it was just a suggestion and if people think zope.pagetemplate is a bit of a dead end, then maybe I should invest the time on chameleon
I think zope.pagetemplate is a dead end for anyone not using one of the large frameworks. Hanno
HI Hanno Changing the default expression is easy. z3c.pt does exactly that to
keep compatibility with zope.tal.
Just found it too, looks like it might be the right place to start. The other thing I am trying to find is batch compiling all of the templates. I can't rely on 100% coverage in dev for all of the templates to be compiled with chameleon before deployment to appengine, have been hunting around for some docs on this. Any pointers ? T
So at this point chameleon needs to be api/implementation compatible with zope.pagetemplates (metal included) or its a big job shifting.
It is 99% compatibile. The only real difference is, that it requires all your templates to be valid XHTML. Otherwise almost all of Zope2/Plone with all kinds of weird code works.
Hey it was just a suggestion and if people think zope.pagetemplate is a bit of a dead end, then maybe I should invest the time on chameleon
I think zope.pagetemplate is a dead end for anyone not using one of the large frameworks.
Hanno
On Thu, Aug 12, 2010 at 12:10 PM, Tim Hoffman <zutesmog@gmail.com> wrote:
The other thing I am trying to find is batch compiling all of the templates. I can't rely on 100% coverage in dev for all of the templates to be compiled with chameleon before deployment to appengine, have been hunting around for some docs on this. Any pointers ?
http://chameleon.repoze.org/docs/latest/config.html The CHAMELEON_EAGER option to be precise. Hanno
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:
Hi.
On Thu, Aug 12, 2010 at 7:36 AM, Tim Hoffman <zutesmog@gmail.com> wrote:
I have been using zope.pagetemplate for quite some time within repoze.bfg projects and bobo (+zope.component) on google appengine (python 2.5.x).
Is there a reason why you don't use Chameleon? Since version 1.1 it should be fully compatible with GAE.
It might be easier to switch to the new kid, instead of trying to make the highly integrated zope.pagetemplate work for you.
So now for my modest proposal, do you think it would be feasible to move the restricted engine implementations out of zope.pagetemplate.engine and into some higher level package and provide a simple trusted engine that anyone can use (that supports metal as well)
At least Zope2 depends on this engine, so moving the engine out into a zope.app.* package is not an option, it would have to be some new zope.* package. I'm not sure what and how BlueBream and Grok use this.
If people think this is a good idea, I am quite willing work on this (with guidance ;-), so thoughts, comments welcome.
I'd like to hear the reasons for not using Chameleon. To me that looks like the better forward path and avoid lots of adjustments and a lengthy migration period for zope.pagetemplate users.
Making the zope.security dependency "soft" seems reasonable to me, especially given that Tim was able to use the package successfully without having it present. - - Make imports from zope.security conditional - - Only define the "untrusted" handlers (and their test) if the imports succeeded. - - Add an 'extra' in setup which makes the dependency explicit. 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkxkHfsACgkQ+gerLs4ltQ4sBwCeNUqcYWEWOMQZ1CasnKTXKhcJ DIAAoIOZff7sxXiw1k79USXlmGc0hTld =N6EW -----END PGP SIGNATURE-----
participants (3)
-
Hanno Schlichting -
Tim Hoffman -
Tres Seaver