[Zope-Annce] [ANN] Zope 2.10.2 released
The Zope developer community I is pleased to announce the release of Zope 2.10.2. You can download Zope 2.10.2 from: http://www.zope.org/Products/Zope/2.10.2/ This release uses unicode as internal representation for ZPT. For this reason you are strongly encouraged to read http://www.zope.org/Products/Zope/2.10.2b1/Zope-2.10.2_released carefully. Some new features of Zope 2.10: - ZPT implementation based on Zope 3 - experimental WSGI and Twisted integration - Zope 3.3, Five 1.5 integration - clock server - lots of minor improvements and fixes - replaced several Zope 2 modules with their sister implementation of Zope 3 For more information on what is new in this release, see the CHANGES.txt files for the release: http://www.zope.org/Products/Zope/2.10.2/CHANGES.txt Please bring all the bugs you have found to the Zope bugtracker: http://collector.zope.org/Zope For more information on the available Zope releases, guidance for selecting the right distribution and installation instructions, please see: http://www.plope.com/Books/2_7Edition/InstallingZope.stx Supported Python versions: Zope 2.10 requires Python 2.4.3+ (Python 2.4.2 is still acceptable). Older Python versions are no longer supported. Using Python 2.5 is also *unsupported*. - -- Andreas Jung -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope Plone development, Consulting pgpAVQee5MJkV.pgp Description: PGP signature ___ Zope-Announce maillist - Zope-Announce@zope.org http://mail.zope.org/mailman/listinfo/zope-announce Zope-Announce for Announcements only - no discussions (Related lists - Users: http://mail.zope.org/mailman/listinfo/zope Developers: http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-Annce] [ANN] Zope 2.10.2 released
--On 25. Januar 2007 18:37:03 +0100 Andreas Jung [EMAIL PROTECTED] wrote: The Zope developer community I is pleased to announce the release of Zope 2.10.2. You can download Zope 2.10.2 from: http://www.zope.org/Products/Zope/2.10.2/ This release uses unicode as internal representation for ZPT. For this reason you are strongly encouraged to read http://www.zope.org/Products/Zope/2.10.2b1/Zope-2.10.2_released carefully. Sorry for posting a broken link. The correct one is: http://www.zope.org/Products/Zope/2.10.2/Zope-2.10.2-released Andreas pgpdTwgs9Ebs5.pgp Description: PGP signature ___ Zope-Announce maillist - Zope-Announce@zope.org http://mail.zope.org/mailman/listinfo/zope-announce Zope-Announce for Announcements only - no discussions (Related lists - Users: http://mail.zope.org/mailman/listinfo/zope Developers: http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-Checkins] SVN: Zope/branches/2.10/ preparing 2.10.2
Log message for revision 72221: preparing 2.10.2 Changed: U Zope/branches/2.10/doc/CHANGES.txt U Zope/branches/2.10/inst/WinBuilders/mk/zope.mk U Zope/branches/2.10/inst/versions.py -=- Modified: Zope/branches/2.10/doc/CHANGES.txt === --- Zope/branches/2.10/doc/CHANGES.txt 2007-01-24 23:45:25 UTC (rev 72220) +++ Zope/branches/2.10/doc/CHANGES.txt 2007-01-25 16:54:30 UTC (rev 72221) @@ -4,7 +4,7 @@ Change information for previous versions of Zope can be found in the file HISTORY.txt. - Zope 2.10.2 (unreleased) + Zope 2.10.2 (2007/01/26) Bugs fixed Modified: Zope/branches/2.10/inst/WinBuilders/mk/zope.mk === --- Zope/branches/2.10/inst/WinBuilders/mk/zope.mk 2007-01-24 23:45:25 UTC (rev 72220) +++ Zope/branches/2.10/inst/WinBuilders/mk/zope.mk 2007-01-25 16:54:30 UTC (rev 72221) @@ -1,4 +1,4 @@ -ZOPEVERSION = 2.10.2-beta-1 +ZOPEVERSION = 2.10.2-final ZOPEDIRNAME := Zope-$(ZOPEVERSION) ZOPE_REQUIRED_FILES=tmp/$(ZOPEDIRNAME).tgz Modified: Zope/branches/2.10/inst/versions.py === --- Zope/branches/2.10/inst/versions.py 2007-01-24 23:45:25 UTC (rev 72220) +++ Zope/branches/2.10/inst/versions.py 2007-01-25 16:54:30 UTC (rev 72221) @@ -4,4 +4,4 @@ # always start prerelease branches with '0' to avoid upgrade # issues in RPMs -VERSION_RELEASE_TAG = 'b1' +VERSION_RELEASE_TAG = 'final' ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/tags/2.10.2/ Zope 2.10.2
Log message for revision 7: Zope 2.10.2 Changed: A Zope/tags/2.10.2/ -=- Copied: Zope/tags/2.10.2 (from rev 72221, Zope/branches/2.10) ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-dev] Zope Tests: 7 OK
Summary of messages to the zope-tests list. Period Wed Jan 24 12:00:00 2007 UTC to Thu Jan 25 12:00:00 2007 UTC. There were 7 messages: 7 from Zope Unit Tests. Tests passed OK --- Subject: OK : Zope-2.6 Python-2.1.3 : Linux From: Zope Unit Tests Date: Wed Jan 24 21:07:46 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007111.html Subject: OK : Zope-2.6 Python-2.3.6 : Linux From: Zope Unit Tests Date: Wed Jan 24 21:09:17 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007112.html Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Wed Jan 24 21:10:47 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007113.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Wed Jan 24 21:12:17 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007114.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Wed Jan 24 21:13:47 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007115.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Wed Jan 24 21:15:17 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007116.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Wed Jan 24 21:16:47 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007117.html ___ 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 )
Re: [Zope-dev] RFC: Eggifying Zope's extension mechanism (Products)
Philipp von Weitershausen wrote: For their upcoming versions, Zope 2 consuming platforms such as Plone are creating standard Zope3-style Python packages while still having Zope 2 products around. This proposal aims at unifying the deployment of products and Python packages into a Zope 2 instance alike by using Python eggs and their entry point system. See http://wiki.zope.org/zope2/EggifyingZopesExtensionMechanismQuotProductsQuot for the full proposal. Comments are appreciated. I plan on implementing it at the Camp5 BBQ sprint (http://www.openplans.org/projects/bbq-sprint) So, to be clear: - You would have lib/python/Products/CMFCore as an alternative to Products/CMFCore - Products in lib/python would be picked up by entry point rather than scanning Products/ - The entry points would work with non-products as well, e.g. if lib/python/plone/foobar had the entry point, it could be a project - This would supersede the five:registerProduct directive we have now If so, this sounds great, so +1 :) I do wonder what would happen if you had both lib/python/Products/CMFCore and Products/CMFCore, though. Would there be an explicit preference or would Zope fail to start up with a conflict? I think I'd prefer the latter, in fact, so that people don't end up modifying/upgrading the wrong code by accident! Martin -- View this message in context: http://www.nabble.com/RFC%3A-Eggifying-Zope%27s-extension-mechanism-%28%22Products%22%29-tf3077929.html#a8612115 Sent from the Zope - Dev mailing list archive at Nabble.com. ___ 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 )
Re: [Zope-dev] RFC: Acquisition and __parent__ pointers
Philipp von Weitershausen wrote: This proposal aims at bringing Zope 2 a bit closer to Zope 3 by making the widely used Acquisition API aware of Zope 3's __parent__ pointers. This will alleviate the need of using Acquisition base classes in Zope 2 for every security-sensitive object, be it persistent or just a dynamically looked up component such as a view. The goal is to enable the use of Zope 3 components in Zope 2 straight away without creating subclasses that mix in Acquisition for security's sake. See http://wiki.zope.org/zope2/AcquisitionAndParentPointers for the full proposal. Comments are appreciated. I expect little resistance to this as it pretty much doesn't change any existing semantics and just makes all of our lives much simpler. Also, if it helps, this has been blessed by Jim in discussion at the EuroPython 2006 sprint. Very strong +1 from me The biggest pain in my ass when coding for Zope 2 these days is that I want to use views and I have to understand a lot of detail about how acquisition works to avoid strange and hard-to-debug errors. If I could stop mixing Acquisition.Explicit into my views, life would be so much better. As for the implementation, I gave it my best shot in the philikon-aq-and-__parent__ branch. My experience with C is limited, especially when it comes to debugging. Help is therefore highly appreciated. There's a reward waiting for whoever fixes the problem and helps getting the branch merged to the trunk (see the proposal text). I guess this is the challenge. Who wants to code C? :) Who even understand this code? (looking at people like Jim and Dieter...) Martin -- View this message in context: http://www.nabble.com/RFC%3A-Acquisition-and-__parent__-pointers-tf3078248.html#a8612767 Sent from the Zope - Dev mailing list archive at Nabble.com. ___ 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 )
[Zope-dev] Re: RFC: Eggifying Zope's extension mechanism (Products)
On Thu, 2007-25-01 at 05:07 -0800, Martin Aspeli wrote: I do wonder what would happen if you had both lib/python/Products/CMFCore and Products/CMFCore, though. Would there be an explicit preference or would Zope fail to start up with a conflict? I think I'd prefer the latter, in fact, so that people don't end up modifying/upgrading the wrong code by accident! Well, we could probably add conflict-detection to the entry point handlers for Zope (ie so any two packages that try to register as the same project would cause an error). But regarding Products/CMFCore and lib/python/Products/CMFCore conflicting... that would be up to the standard pythonpath mechanism of the python interpreter (whichever is first on the path wins). - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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 )
[Zope-dev] Re: RFC: Eggifying Zope's extension mechanism (Products)
Rocky Burt wrote:
On Thu, 2007-25-01 at 05:07 -0800, Martin Aspeli wrote:
I do wonder what would happen if you had both lib/python/Products/CMFCore
and Products/CMFCore, though. Would there be an explicit preference or would
Zope fail to start up with a conflict? I think I'd prefer the latter, in
fact, so that people don't end up modifying/upgrading the wrong code by
accident!
Well, we could probably add conflict-detection to the entry point
handlers for Zope (ie so any two packages that try to register as the
same project would cause an error). But regarding Products/CMFCore and
lib/python/Products/CMFCore conflicting... that would be up to the
standard pythonpath mechanism of the python interpreter (whichever is
first on the path wins).
Zope 2 itself manipulates Products.__path__ to add INSTANCE/Products (or
any other directory specified in zope.conf) as a directory which can
contain further products (the original Products package lives at
ZOPE/lib/python/Products). pkg_resources uses the same mechanism for
namespace packages (that's what the
pkg_resources.declare_namespace('Products') call is all about); it
appends to __path__.
Therefore, Zope will treat /path/to/the/CMFCore-egg/Products as another
directory that contains a product (in this case just one, CMFCore). Thus
the standard product override rules apply when the same product is
installed in multiple directories.
I updated the proposal text with this information.
--
http://worldcookery.com -- Professional Zope documentation and training
Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5
___
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 )
[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
whit wrote: Martin Aspeli wrote: Philipp von Weitershausen wrote: This is awesome, and by that I don't mean the fact that we have a plone buildout, but that we actually have Zope 2 recipes for buildout. I hope they can be moved to svn.zope.org for further development to benefit the whole Zope 2 community. I believe this is just a matter of contrib agreements being sorted out (Hanno?). I guess I need to get mine sorted out as well if I'm going to keep working on this when it moves... :-/ I also see that workingenv was abandoned. That's very good to hear because buildout has a lot of machinery for installing eggs already, it would just've been duplicated with workingenv... is there some advantage to the way that buildout handles eggs over workingenv. as I understand it, workingenv *only* handles python setup and does that well and transparently. The point is that buildout *already* handles eggs. There's really no point for having an extra layer on top of buildout. The zc.recipe.egg recipe can install any egg (as a development one or not) in an automated fashion, which is exactly what you'd want from a buildout. the source bin/activate dance is the only thing I see being a detriment here(and with the latest workingenv, your shell prompt lets you know you are in an env). Not everybody likes the activate dance. With buildout, you don't need it. The recipes make sure that the scripts that get installed into the buildout's 'bin' directory have the right PYTHONPATH set and have access to the eggs you requested for the buildout. Workingenv made it more complex than it needed to be (or buildout did, depending on which perspective you look at it from). I believe Hanno wanted to rescue the recipe in case others found it useful, but it's not used for now. what about if I'm already using workingenv... and want to use zope or plone in my workingenv? I see no problem with that. zc.buildout is one way of deploying Python software like Zope. As long as you've got eggs, you could install them manually into your workingenv just fine. buildout just does it an automated fashion (and, of course, it can do more than just installing eggs). currently, I don't see an easy way to use buildouts inside a workingenv, whereas the rest of python world works great. I will have alot of trouble explaining to my developer who already think zope smells that they have to change the way they work to use zc.buildout recipes. for example, I can't use the deliverance or lxml buildout with an existing topp.deploy workingenv because of buildout's arbitrary egg handling scheme. If zc.buildout didn't try to do so much, the python would be installed transparently like everything else I easy_install. I'm not too fond of zc.buildout's directory scheme eiher. In particular, I wish that it would use 'lib/python' instead of 'eggs' and 'src' instead of 'develop-eggs'. I don't know enough zc.buildout details to be able to say whether that can be chagned by remimplementing the egg installation recipe. I would sure hope it is. as stated before, I don't mind using zc.buildout, but I don't want to have to learn zc.buildout to use it meaningfully in my existing setup. If a buildout recipes could be executed by themselves(like buildout-zope2, buildout-deliverance, buildout-squid) as well as by aggregated recipes. This would make buildout a killer tool inside my workingenv rather than a choice I had to make between two technologies. As said already, I think once you've got buildout, there's no need for workingen, except if you think that Zope stinks ;) -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ 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 )
[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
Philipp von Weitershausen wrote:
The point is that buildout *already* handles eggs. There's really no
point for having an extra layer on top of buildout. The zc.recipe.egg
recipe can install any egg (as a development one or not) in an automated
fashion, which is exactly what you'd want from a buildout.
At least it's what I want. That is, easy_install may as well put things
in the ether as far as I'm concerned, and I'm more comfortable with a
single file (buildout.cfg) that gives me an overview of which eggs my
application consists of.
Very open to be persuaded otherwise, though. ;-)
the source bin/activate dance is the only thing I see being a
detriment here(and with the latest workingenv, your shell prompt lets
you know you are in an env).
Not everybody likes the activate dance. With buildout, you don't need
it. The recipes make sure that the scripts that get installed into the
buildout's 'bin' directory have the right PYTHONPATH set and have access
to the eggs you requested for the buildout.
On the one hand, this patching is a bit odd, but probably just a result
of the fact that Zope itself isn't terribly egg/pythonpath friendly. On
the other hand, I don't like the stateful nature of the activate dance
to point where it feels hacky to me. I know others disagree, though.
I see no problem with that. zc.buildout is one way of deploying Python
software like Zope. As long as you've got eggs, you could install them
manually into your workingenv just fine. buildout just does it an
automated fashion (and, of course, it can do more than just installing
eggs).
... and I've come to like its approach to stringing together recipes and
passing options. It fits my brain. :)
I'm not too fond of zc.buildout's directory scheme eiher. In particular,
I wish that it would use 'lib/python' instead of 'eggs' and 'src'
instead of 'develop-eggs'. I don't know enough zc.buildout details to be
able to say whether that can be chagned by remimplementing the egg
installation recipe. I would sure hope it is.
in buildout.cfg, I did:
[buildout]
eggs-directory = lib/python
develop-eggs-directory = lib/python
Eggs are now in ${buildout}/lib/python, and it seems to work fine (but I
had to stop short of testing in detail). I imagine that if workingenv
was told of the same directory, the two would co-exist.
I want to play with the zope 2 recipies to make filesystem layout a bit
more flexible in these.
as stated before, I don't mind using zc.buildout, but I don't want to
have to learn zc.buildout to use it meaningfully in my existing setup.
If a buildout recipes could be executed by themselves(like
buildout-zope2, buildout-deliverance, buildout-squid) as well as by
aggregated recipes. This would make buildout a killer tool inside my
workingenv rather than a choice I had to make between two technologies.
As said already, I think once you've got buildout, there's no need for
workingen, except if you think that Zope stinks ;)
Plone stinks!
Martin
___
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 )
[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
Philipp von Weitershausen wrote: whit wrote: Martin Aspeli wrote: Philipp von Weitershausen wrote: This is awesome, and by that I don't mean the fact that we have a plone buildout, but that we actually have Zope 2 recipes for buildout. I hope they can be moved to svn.zope.org for further development to benefit the whole Zope 2 community. I believe this is just a matter of contrib agreements being sorted out (Hanno?). I guess I need to get mine sorted out as well if I'm going to keep working on this when it moves... :-/ I also see that workingenv was abandoned. That's very good to hear because buildout has a lot of machinery for installing eggs already, it would just've been duplicated with workingenv... is there some advantage to the way that buildout handles eggs over workingenv. as I understand it, workingenv *only* handles python setup and does that well and transparently. The point is that buildout *already* handles eggs. There's really no point for having an extra layer on top of buildout. The zc.recipe.egg recipe can install any egg (as a development one or not) in an automated fashion, which is exactly what you'd want from a buildout. honestly, it seems to me that buildout tries to do too much. it's trying to handle both repeatable deployment recipes AND providing a sandbox within which to run things. there may not be a point to having an extra layer on top of buildout, but buildout sure does seem to me a bit heavy if all i want is a sandbox. so now i have to learn the workingenv way if i just need a sandbox, but i have to learn the buildout way if i also want repeatable deployments? Workingenv made it more complex than it needed to be (or buildout as stated before, I don't mind using zc.buildout, but I don't want to have to learn zc.buildout to use it meaningfully in my existing setup. If a buildout recipes could be executed by themselves(like buildout-zope2, buildout-deliverance, buildout-squid) as well as by aggregated recipes. This would make buildout a killer tool inside my workingenv rather than a choice I had to make between two technologies. As said already, I think once you've got buildout, there's no need for workingen, except if you think that Zope stinks ;) this is shortsighted, IMO. i know zope quite well, but i bounced off of buildout b/c it required too much knowledge to even get started. i think it's much more likely that people from the greater python community will pick up and start using workingenv than they will zc.buildout. personally, i like chris mcdonough's approach with his buildit package. it does two things: - it retrieves files from anywhere on the 'net (cvs, svn, tarball, whatever) and puts them where you want them on your target machine(s) - it launches external scripts that then perform whatever final configuration you may want to perform. buildit is also recipe driven, and it's smart enough to pick up where it left off on a previous run, a'la make. i'd guess that you could use buildit and workingenv to accomplish pretty much everything you can do w/ zc.buildout, and you wouldn't have to bend your brain so much to do so. -r ___ 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 )
[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
On Thu, 25 Jan 2007 12:45:26 -0800, Martin Aspeli [EMAIL PROTECTED] wrote: Plone stinks! It's like a fine cheese. -- Alexander Limi · http://limi.net ___ 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 )
[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
Philipp von Weitershausen wrote: whit wrote: Martin Aspeli wrote: Philipp von Weitershausen wrote: This is awesome, and by that I don't mean the fact that we have a plone buildout, but that we actually have Zope 2 recipes for buildout. I hope they can be moved to svn.zope.org for further development to benefit the whole Zope 2 community. I believe this is just a matter of contrib agreements being sorted out (Hanno?). I guess I need to get mine sorted out as well if I'm going to keep working on this when it moves... :-/ I also see that workingenv was abandoned. That's very good to hear because buildout has a lot of machinery for installing eggs already, it would just've been duplicated with workingenv... is there some advantage to the way that buildout handles eggs over workingenv. as I understand it, workingenv *only* handles python setup and does that well and transparently. The point is that buildout *already* handles eggs. There's really no point for having an extra layer on top of buildout. The zc.recipe.egg recipe can install any egg (as a development one or not) in an automated fashion, which is exactly what you'd want from a buildout. well that's awesome that buildout has duplicated this effort the source bin/activate dance is the only thing I see being a detriment here(and with the latest workingenv, your shell prompt lets you know you are in an env). Not everybody likes the activate dance. With buildout, you don't need it. The recipes make sure that the scripts that get installed into the buildout's 'bin' directory have the right PYTHONPATH set and have access to the eggs you requested for the buildout. is there really a difference between zopectl and source bin/activate? I guess the main difference here is where PYTHONPATH gets set and how people work with it. for example, if you just start python and want to play with code sounds like with zc.buildout you are out of luck for things installed in the buildout. In our situation, we might have multiple versions of software running on different processes started in different workingenv (often not even using zope).being able to contextualize the python path is a useful development tool; this is understandable for buildout to avoid(as a deployment tool), but if we are considering using buildout as a prescribed way for people to manage their development environments, it seems lacking. Workingenv made it more complex than it needed to be (or buildout did, depending on which perspective you look at it from). I believe Hanno wanted to rescue the recipe in case others found it useful, but it's not used for now. what about if I'm already using workingenv... and want to use zope or plone in my workingenv? I see no problem with that. zc.buildout is one way of deploying Python software like Zope. As long as you've got eggs, you could install them manually into your workingenv just fine. buildout just does it an automated fashion (and, of course, it can do more than just installing eggs). which I could automate in my env (workingenv takes recipes also). for that matter, eggs automate the installation of eggs... I'm not sure what it would take to make buildout just automate install eggs into my env... but not putting them in special directories would be a start. currently, I don't see an easy way to use buildouts inside a workingenv, whereas the rest of python world works great. I will have alot of trouble explaining to my developer who already think zope smells that they have to change the way they work to use zc.buildout recipes. for example, I can't use the deliverance or lxml buildout with an existing topp.deploy workingenv because of buildout's arbitrary egg handling scheme. If zc.buildout didn't try to do so much, the python would be installed transparently like everything else I easy_install. I'm not too fond of zc.buildout's directory scheme eiher. In particular, I wish that it would use 'lib/python' instead of 'eggs' and 'src' instead of 'develop-eggs'. I don't know enough zc.buildout details to be able to say whether that can be chagned by remimplementing the egg installation recipe. I would sure hope it is. +1 this may be all that is required to make the two play well together(or have buildout respect an existing workingenv when doing it's local install of eggs). Maybe it's just a matter of zc.buildout seeing workingenv is in effect and not composing special pythonpaths. harmony is my interest here. workingenv is pretty low-level and works hard to work well with python. there is no reason that zc.buildout should have a problem with that.. it just needs to do less when appropriate. as stated before, I don't mind using zc.buildout, but I don't want to have to learn zc.buildout to use it meaningfully in my existing setup. If a buildout recipes could be executed by themselves(like buildout-zope2, buildout-deliverance, buildout-squid) as
[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
whit wrote: Not everybody likes the activate dance. With buildout, you don't need it. The recipes make sure that the scripts that get installed into the buildout's 'bin' directory have the right PYTHONPATH set and have access to the eggs you requested for the buildout. is there really a difference between zopectl and source bin/activate? I guess the main difference here is where PYTHONPATH gets set and how people work with it. for example, if you just start python and want to play with code sounds like with zc.buildout you are out of luck for things installed in the buildout. In our situation, we might have multiple versions of software running on different processes started in different workingenv (often not even using zope).being able to contextualize the python path is a useful development tool; this is understandable for buildout to avoid(as a deployment tool), but if we are considering using buildout as a prescribed way for people to manage their development environments, it seems lacking. I think this is the basic difference -- workingenv is development-centric, while buildout is deployment-centric. This does not necessarily mean the best tool for the job, because focusing on development and ignore deployment isn't a good job, nor the other way around. At TOPP we know how to address both stories with workingenv. We haven't figured it out with buildout, despite trying. And we definitely aren't satisfied with just a deployment tool that doesn't address our development needs. But there's a lot of use cases for Plone specifically where carefully developing just a deployment solution makes sense. That doesn't make sense for us, because we're not in the kind of consulting business where the relative scale of development and deployment works like that. But eh; the presence of a buildout for Plone doesn't hurt our position any. Anything that gets rid of another ad hoc crappy deployment is good by me. And if other people are working on it, all the better! If *Plone* becomes incompatible with workingenv that'd be bothersome (though it was not compatible with workingenv without some work in the first place). But if a buildout is incompatible, eh... who knows, it might even make sense to create something like a freeze this workingenv as a buildout script. That one directory structure can't be both at the same time isn't a huge problem in my mind. I'm not too fond of zc.buildout's directory scheme eiher. In particular, I wish that it would use 'lib/python' instead of 'eggs' and 'src' instead of 'develop-eggs'. I don't know enough zc.buildout details to be able to say whether that can be chagned by remimplementing the egg installation recipe. I would sure hope it is. +1 this may be all that is required to make the two play well together(or have buildout respect an existing workingenv when doing it's local install of eggs). Maybe it's just a matter of zc.buildout seeing workingenv is in effect and not composing special pythonpaths. harmony is my interest here. workingenv is pretty low-level and works hard to work well with python. there is no reason that zc.buildout should have a problem with that.. it just needs to do less when appropriate. Path names aren't really the problem. We got a little guerrilla war going on over the setuptools' script-generating monkey patches. We'd both probably prefer a proper way to change how setuptools generates scripts, but it's not clear that we could really be compatible -- enumeration vs. changing the path is a totally different strategy. I'd rather see easy-install.pth become a better package database, or some other strategy of external requirement specifications, instead of building it into scripts. I understand the issue Jim is trying to solve here, but putting everything into the buildout.cfg and then imperatively setting up the files from there bothers me and does not make development easy IMHO. That's mostly the problem. Then workingenv would do its part by monkeypatching distutils and setuptools to install things locally, and changing site.py to not automatically pick up things globally. And buildout could do its stuff that applies to other more complicated setups than just setting up some libraries, which is about where workingenv stops. Well, what I'd *really* like is an idea of a working environment that applies more widely than Python, because other languages (including but not limited to the dynamic languages) have all these same problems, and we all have half-assed solutions. But I don't even know how to start that conversation. And don't get me started on how the distributions are going to look at all this! Ian ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists -
Re: [Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
I hate to jump into this thread but I'll make a few comments. On Jan 25, 2007, at 5:13 PM, whit wrote: Philipp von Weitershausen wrote: whit wrote: Martin Aspeli wrote: Philipp von Weitershausen wrote: This is awesome, and by that I don't mean the fact that we have a plone buildout, but that we actually have Zope 2 recipes for buildout. I hope they can be moved to svn.zope.org for further development to benefit the whole Zope 2 community. I believe this is just a matter of contrib agreements being sorted out (Hanno?). I guess I need to get mine sorted out as well if I'm going to keep working on this when it moves... :-/ I also see that workingenv was abandoned. That's very good to hear because buildout has a lot of machinery for installing eggs already, it would just've been duplicated with workingenv... is there some advantage to the way that buildout handles eggs over workingenv. as I understand it, workingenv *only* handles python setup and does that well and transparently. Right, buildout handles a lot more. For example, we use buildout to build C libraries and to generate various sorts of application artifacts like configuration files, custom startup scripts, and so on, in addition to Python scripts. The point is that buildout *already* handles eggs. There's really no point for having an extra layer on top of buildout. The zc.recipe.egg recipe can install any egg (as a development one or not) in an automated fashion, which is exactly what you'd want from a buildout. well that's awesome that buildout has duplicated this effort I'm not sure what effort you think buildout is duplicating. WRT eggs, buildout, like workinenv/easy_install builds on setuptools. setuptools does the heavy lifting with regard to building eggs. Buildout does have some nice features for building eggs with extensions that need custom setup options. Like workenv, buildout supports installing eggs in development environments rather than the system Python. workingenv bends easy_install to it's will, while buildout goes below easy_install. This allows buildout to have more control, which was important to me. Buildout gives me greater control over egg revisions used and the way that scripts get generated. (Maybe workingenv would give me more control than I think it does -- I haven't looked at it in a while.) the source bin/activate dance is the only thing I see being a detriment here(and with the latest workingenv, your shell prompt lets you know you are in an env). Not everybody likes the activate dance. With buildout, you don't need it. The recipes make sure that the scripts that get installed into the buildout's 'bin' directory have the right PYTHONPATH set and have access to the eggs you requested for the buildout. is there really a difference between zopectl and source bin/ activate? I guess the main difference here is where PYTHONPATH gets set and how people work with it. for example, if you just start python and want to play with code sounds like with zc.buildout you are out of luck for things installed in the buildout. I'm not sure what you mean here. I'll note that buildout lets you easily create interpreter scripts. When run without arguments, you get a Python prompt. When run with a script name and arguments, then they will run the script with the arguments. You define an interpreter by specifying on or more eggs and those eggs and their dependencies (and additional paths you can optionally set) will be included in the interpreter's path. This makes playing with code pretty easy. In our situation, we might have multiple versions of software running on different processes started in different workingenv (often not even using zope).being able to contextualize the python path is a useful development tool; this is understandable for buildout to avoid(as a deployment tool), but if we are considering using buildout as a prescribed way for people to manage their development environments, it seems lacking. I don't know what you mean by contextualize the python path. An important feature of buildout (actualy the egg recipe) is that it lets you create scripts with exactly the eggs they need. This was a core motivation of buildout. And, as I have mentioned above, you can also create interpreter scripts for experimentation and running other scripts. Perhaps these interpreter scripts are like your workingenvs. Workingenv made it more complex than it needed to be (or buildout did, depending on which perspective you look at it from). I believe Hanno wanted to rescue the recipe in case others found it useful, but it's not used for now. what about if I'm already using workingenv... and want to use zope or plone in my workingenv? I see no problem with that. zc.buildout is one way of deploying Python software like Zope. As long as you've got eggs,
Re: [Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
On Jan 25, 2007, at 5:09 PM, Ian Bicking wrote: Whit pointed me to this thread. Yeah, someone pointed me to it too. :) I won't reply to specifics, but maybe just describe what we're doing (and planning to do), and how workingenv differs from zc.buildout. I'll avoid responding to general qualitative statements. ... I actually tried to do this once before with zc.buildout, but I didn't get far -- probably a result of lack of effort and lack of familiarity with the overall stack. But I also recognize lots of the questions about stuff like the zope.conf file and Data.fs that still seem unresolved. Certainly when you tried this, buildout was very young and we hadn't written recipes to deal with these issues. We've made a lot of progress since then. The thing that frustrated me with zc.buildout is that I knew how to do what I wanted to do, but I still felt like I was a long way from being able to do it. And little things, like unhelpful error messages Yeah, buildout still needs to do a lot better with error messages, although it has probably made some progress since you tried it. and frustratingly slow performance really killed my motivation. That has improved quite a bit. ... And frankly I like easy_install. It's probably 10x faster than buildout. I doubt that that is true now. Although that probably depends on what you are doing. Early versions of buildout did a lot of things inefficiently as I was still learning setuptools. Because of the way that buildout caches index information, I expect that creating a buildout from scratch that used a lot of eggs would be much faster than using easy_install. One difference though is that buildout checks for the most recent compatible versions of all of the eggs it's using every time you run it, whereas, as I understand it, with workingenv, you'd just run easy_install manually when you want a new egg. You can bypass the checks by running in offline mode. Then buildout runs very fast. Because of the ability to share eggs accross buildouts, it is often possible to run a buidout using lots of eggs in offline mode. It has been suggested that there should be a mode for buildout that only talks to the network when there isn't a local egg that satisfied a requirement. This would make buildout work more like workingenv when few if any eggs are actually needed. easy_install is what people use in documentation, and its conventions are the ones people know (why does buildout not use Pkg==version, for instance?). It does. When specifying eggs, you use standard setuptools requirement syntax. As for the technical reasons they don't work together: * workingenv allows and leaves it to setuptools to maintain the package installation database (basically easy-install.pth). This is not a very good database, but eh. buildout doesn't really have a database, but instead just enforces what buildout.cfg indicates. buildout uses the buildout configuration file to store what you want. It uses .installed.cfg to capture what you have. These are both databases of sorts. * workingenv relies on that database to give default versions and to setup the Python path. The fixup it does of installed scripts is fairly minimal, just setting up sys.path enough to force its site.py to get called. buildout enumerates all the activated packages, and ignores easy-install.pth. This is basically what makes it easy_install-incompatible. Yup. I wanted something far more static and predictable for scripts generated by buildout. Plus buildout's desire to own everything and destroy everything it does not own ;) I'm not aware that it destroys anything. Could you be more specific? * As a result buildout supports multiple things in the same buildout that have conflicting version requirements, but where the packages themselves don't realize this (but the deployer does). If the packages know their requirements then setuptools' native machinery allows things to work fine. Yes. I expect that usually, packages won't be very specific. The buildout configuration file provides a place to be specific. * Some see bin/activate as a jail. Both workingenv and buildout are deliberately jail-like. Both Jim and I loathe the non- repeatability of system-wide installations (at least I think I can speak for him on that one point ;). bin/activate lets you into that jail, and lets you work there. There is no way into a buildout. I'm not familiar with bin/activate, but it sounds like an interpreter script created with buildout. Frankly this weirds me out, and is a big part of my past frustration with it. Maybe that's because I'm in the relatively uncommon situation that I actually know what's going on under the hood of Python imports and packaging, and so it bothers me that I can't debug things directly. Anyway, neither requires activation when using scripts generated
Re: [Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
On Jan 25, 2007, at 5:44 PM, Ian Bicking wrote: workingenv is development-centric, while buildout is deployment- centric. This does not necessarily mean the best tool for the job, because focusing on development and ignore deployment isn't a good job, nor the other way around. buildout focusses on both. ... If *Plone* becomes incompatible with workingenv that'd be bothersome I agree. But if a buildout is incompatible, eh... who knows, I would hope that buildout would not have to be compatible with workingenv, whatever that means, in order for Plone to be compatible. Then again, I'm not sure what compatibility means in this context. it might even make sense to create something like a freeze this workingenv as a buildout script. That one directory structure can't be both at the same time isn't a huge problem in my mind. Deployment involves far more than getting the software installed. ... Path names aren't really the problem. We got a little guerrilla war going on over the setuptools' script-generating monkey patches. We'd both probably prefer a proper way to change how setuptools generates scripts, but it's not clear that we could really be compatible -- enumeration vs. changing the path is a totally different strategy. Um, we're both changing the path -- just in different ways. I'd rather see easy-install.pth become a better package database, or some other strategy of external requirement specifications, instead of building it into scripts. We certainly disagree there. OTOH, I wouldn't be opposed to having a recipe for generating scripts that used the .pth files created by workingenv. I understand the issue Jim is trying to solve here, but putting everything into the buildout.cfg and then imperatively setting up the files from there bothers me and does not make development easy IMHO. This seems to be a matter of taste. I like developing with buildout. It makes development easier for me. :) To each his own. That's mostly the problem. Then workingenv would do its part by monkeypatching distutils and setuptools to install things locally, and changing site.py to not automatically pick up things globally. I applaud you for this effort. I chose to work below easy_install and site.py rather that trying to bend/monkey-path it to my will. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://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 )
Re: [Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
Jim Fulton wrote: If *Plone* becomes incompatible with workingenv that'd be bothersome I agree. But if a buildout is incompatible, eh... who knows, I would hope that buildout would not have to be compatible with workingenv, whatever that means, in order for Plone to be compatible. Then again, I'm not sure what compatibility means in this context. It would be a concern if, for instance, Plone started depending on buildout recipes for installation, without plain distutils recipes. Of course right now there are no distutils recipes for old-style Products. So actually it's an active issue -- if buildout enables Plone to keep from moving to distutils/setuptools/egg-style package deployment (because buildout is flexible enough to support the old patterns) then that would make it harder for workingenv. But I don't think anyone is proposing that buildout means that Plone (and Zope 2/Five) shouldn't continue its move towards traditional Python packaging. So basically I would just hope that Plone doesn't lean to heavily on buildout. it might even make sense to create something like a freeze this workingenv as a buildout script. That one directory structure can't be both at the same time isn't a huge problem in my mind. Deployment involves far more than getting the software installed. Yes; in a workingenv model you start with an environment, then you actually make your deployment using tools of your choice. workingenv doesn't deploy for you. Admittedly your choice isn't always good, because maybe you didn't want to make a choice ;) Path names aren't really the problem. We got a little guerrilla war going on over the setuptools' script-generating monkey patches. We'd both probably prefer a proper way to change how setuptools generates scripts, but it's not clear that we could really be compatible -- enumeration vs. changing the path is a totally different strategy. Um, we're both changing the path -- just in different ways. Maybe enumeration vs adding a directory of eggs is a better description. Setuptools controls the directory of eggs (via easy-install.pth), while buildout controls the scripts and doesn't give setuptools that control. I'd rather see easy-install.pth become a better package database, or some other strategy of external requirement specifications, instead of building it into scripts. We certainly disagree there. OTOH, I wouldn't be opposed to having a recipe for generating scripts that used the .pth files created by workingenv. I'm not sure what the problem would be? I appreciate the desire for a set of requirements that is different from the requirements of the package, and workingenv has some support for that (with the --requirements option), but it's a different style from buildout. easy-install.pth would almost be okay, except for the fact that it is constantly pointing to things that don't exist, has setuptools' hacks in it (to work around the atrocious Python standard site.py), and doesn't describe intent, it's just an enumeration of what is available and activated (i.e., available without specifically requiring something). Besides all that, it's still a workable foundation IMHO. -- 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 )
[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
Rob Miller wrote: honestly, it seems to me that buildout tries to do too much. it's trying to handle both repeatable deployment recipes AND providing a sandbox within which to run things. there may not be a point to having an extra layer on top of buildout, but buildout sure does seem to me a bit heavy if all i want is a sandbox. so now i have to learn the workingenv way if i just need a sandbox, but i have to learn the buildout way if i also want repeatable deployments? Potentially. But I find it kind of reassuring to have a well-defined list of which eggs are part of my special environment i.e. the one tied to my instance. As said already, I think once you've got buildout, there's no need for workingen, except if you think that Zope stinks ;) this is shortsighted, IMO. i know zope quite well, but i bounced off of buildout b/c it required too much knowledge to even get started. i think it's much more likely that people from the greater python community will pick up and start using workingenv than they will zc.buildout. Again, I think the two are orthogonal. And honestly, I found zc.buildout pretty easy to understand. I resisted it for a while, it seems liked it *should* be complex, and I won't pretend to understand how it manages eggs in any detail, but I don't think it matters. Look at http://dev.plone.org/plone/browser/ploneout/trunk/buildout.cfg - I find that pretty self-explanatory. I tried to document how it works at a high level and how you may use it here http://dev.plone.org/plone/browser/ploneout/trunk/README.txt. And writing a new recipe is as simple as this: http://dev.plone.org/plone/browser/ploneout/trunk/src/z2c.recipe.zope2checkout/src/z2c/recipe/zope2checkout/__init__.py All that is plain python code, the only thing you need to understand about buildout is that it has a dict-like object called 'options' which reflects the options in the current part's section in buildout.cfg, and a higher level dict-like object called 'buildout' which has the options for all the parts (so buildout['foo'] are the options for part [foo] in buidout.cfg). Each part is associated with a recipie. Recipies are ordered. personally, i like chris mcdonough's approach with his buildit package. it does two things: - it retrieves files from anywhere on the 'net (cvs, svn, tarball, whatever) and puts them where you want them on your target machine(s) You can do that quite easily with buildout as well. I would like to make a more generic recipe for retrieving tarballs for e.g. zope installation, and I think it'd be as hard as figuring out which python function to use to download something. - it launches external scripts that then perform whatever final configuration you may want to perform. Again, if you want a recipe to do that, it's trivial to write (10 lines of code?). Instead of an external script, though, I would probably find it easier to write that as a buildout recipe in python. buildit is also recipe driven, and it's smart enough to pick up where it left off on a previous run, a'la make. i'd guess that you could use buildit and workingenv to accomplish pretty much everything you can do w/ zc.buildout, and you wouldn't have to bend your brain so much to do so. I'm just struggling to see why it's so hard to figure out how buildout works. Perhaps it just fits my brain. But honestly, once Hanno showed me his initial steps with ploneout and I'd taken ten minutes with pdb inside the __init__() and install() functions (the only two...) in his recipe the pieces fitted together in my head almost instantly. I don't greatly care how the standard zc.recipe.egg mechanism installs eggs because it works and because I can see clearly where they come from, how I create new ones and I'm satisfied that they are available ot my python interpreter. If I did care, I'm sure I wouldn't find it that hard to trace, though. Martin ___ 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 )
Re: [Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
Jim Fulton wrote: I actually tried to do this once before with zc.buildout, but I didn't get far -- probably a result of lack of effort and lack of familiarity with the overall stack. But I also recognize lots of the questions about stuff like the zope.conf file and Data.fs that still seem unresolved. Certainly when you tried this, buildout was very young and we hadn't written recipes to deal with these issues. We've made a lot of progress since then. Well, the last time I really used it was early December, and it still felt slow and awkward to me at the time, with several funny quirks. And frankly I like easy_install. It's probably 10x faster than buildout. I doubt that that is true now. Although that probably depends on what you are doing. Early versions of buildout did a lot of things inefficiently as I was still learning setuptools. Because of the way that buildout caches index information, I expect that creating a buildout from scratch that used a lot of eggs would be much faster than using easy_install. One difference though is that buildout checks for the most recent compatible versions of all of the eggs it's using every time you run it, whereas, as I understand it, with workingenv, you'd just run easy_install manually when you want a new egg. Correct. The basic process with workingenv is: 1. Set it up. 2. Start installing stuff. 3. Try running stuff. 4. Realize you got it wrong, missed something, want to do more development, return to 2. I actually find myself doing the 2-4 loop pretty often, both in development and when first deploying something. Just the amount of time to do bin/buildout -h was substantial (though I don't really understand why, except that buildout seemed to be working way too hard to update itself). You can bypass the checks by running in offline mode. Then buildout runs very fast. Because of the ability to share eggs accross buildouts, it is often possible to run a buidout using lots of eggs in offline mode. It has been suggested that there should be a mode for buildout that only talks to the network when there isn't a local egg that satisfied a requirement. This would make buildout work more like workingenv when few if any eggs are actually needed. Yes; more like easy_install does as well, actually. Though the way easy_install works is hardly intuitive; I find myself frequently saying yes, you installed it, but did you -U install it? As for the technical reasons they don't work together: * workingenv allows and leaves it to setuptools to maintain the package installation database (basically easy-install.pth). This is not a very good database, but eh. buildout doesn't really have a database, but instead just enforces what buildout.cfg indicates. buildout uses the buildout configuration file to store what you want. It uses .installed.cfg to capture what you have. These are both databases of sorts. * workingenv relies on that database to give default versions and to setup the Python path. The fixup it does of installed scripts is fairly minimal, just setting up sys.path enough to force its site.py to get called. buildout enumerates all the activated packages, and ignores easy-install.pth. This is basically what makes it easy_install-incompatible. Yup. I wanted something far more static and predictable for scripts generated by buildout. Plus buildout's desire to own everything and destroy everything it does not own ;) I'm not aware that it destroys anything. Could you be more specific? Well, it owns parts, and the recipes control that. Doesn't it also delete and reinstall there? How it treats each area of the buildout I'm unclear. Simply making the file layout a bit more conventional, and describing anything non-obvious, would make buildout feel a lot more comfortable to the new user. * As a result buildout supports multiple things in the same buildout that have conflicting version requirements, but where the packages themselves don't realize this (but the deployer does). If the packages know their requirements then setuptools' native machinery allows things to work fine. Yes. I expect that usually, packages won't be very specific. The buildout configuration file provides a place to be specific. workingenv allows this, insofar as you can be specific while installing things, and with the requirements file. But it doesn't make the individual scripts very specific, if for instance appfoo requires libX1.0, and appbar requires libX1.1, but you actually want appfoo to use libX==1.0 and appbar to use libX==1.1 and install them in the same buildout. That's the only case where buildout seems to be able to express something workingenv can't. * Some see bin/activate as a jail. Both workingenv and buildout are deliberately jail-like. Both Jim and I loathe the non-repeatability of system-wide installations (at least I think I can speak for him on that one point ;).
[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
Martin Aspeli wrote: Rob Miller wrote: honestly, it seems to me that buildout tries to do too much. it's trying to handle both repeatable deployment recipes AND providing a sandbox within which to run things. there may not be a point to having an extra layer on top of buildout, but buildout sure does seem to me a bit heavy if all i want is a sandbox. so now i have to learn the workingenv way if i just need a sandbox, but i have to learn the buildout way if i also want repeatable deployments? Potentially. But I find it kind of reassuring to have a well-defined list of which eggs are part of my special environment i.e. the one tied to my instance. to find this i simply look in /path/to/workingenv/lib/python2.4. As said already, I think once you've got buildout, there's no need for workingen, except if you think that Zope stinks ;) this is shortsighted, IMO. i know zope quite well, but i bounced off of buildout b/c it required too much knowledge to even get started. i think it's much more likely that people from the greater python community will pick up and start using workingenv than they will zc.buildout. Again, I think the two are orthogonal. orthogonal, but with overlap. And honestly, I found zc.buildout pretty easy to understand. I resisted it for a while, it seems liked it *should* be complex, and I won't pretend to understand how it manages eggs in any detail, but I don't think it matters. Look at http://dev.plone.org/plone/browser/ploneout/trunk/buildout.cfg - I find that pretty self-explanatory. I tried to document how it works at a high level and how you may use it here http://dev.plone.org/plone/browser/ploneout/trunk/README.txt. And writing a new recipe is as simple as this: http://dev.plone.org/plone/browser/ploneout/trunk/src/z2c.recipe.zope2checkout/src/z2c/recipe/zope2checkout/__init__.py All that is plain python code, the only thing you need to understand about buildout is that it has a dict-like object called 'options' which reflects the options in the current part's section in buildout.cfg, and a higher level dict-like object called 'buildout' which has the options for all the parts (so buildout['foo'] are the options for part [foo] in buidout.cfg). Each part is associated with a recipie. Recipies are ordered. personally, i like chris mcdonough's approach with his buildit package. it does two things: - it retrieves files from anywhere on the 'net (cvs, svn, tarball, whatever) and puts them where you want them on your target machine(s) You can do that quite easily with buildout as well. I would like to make a more generic recipe for retrieving tarballs for e.g. zope installation, and I think it'd be as hard as figuring out which python function to use to download something. i have no doubt that zc.buildout will do everything that buildit will do, and probably much more. but i like simple. and for me, having something light like workingenv to manage my sandbox, and a library like buildit for putting files into those sandboxes feels simple. - it launches external scripts that then perform whatever final configuration you may want to perform. Again, if you want a recipe to do that, it's trivial to write (10 lines of code?). Instead of an external script, though, I would probably find it easier to write that as a buildout recipe in python. the script could of course be python as well. buildit is also recipe driven, and it's smart enough to pick up where it left off on a previous run, a'la make. i'd guess that you could use buildit and workingenv to accomplish pretty much everything you can do w/ zc.buildout, and you wouldn't have to bend your brain so much to do so. I'm just struggling to see why it's so hard to figure out how buildout works. Perhaps it just fits my brain. But honestly, once Hanno showed me his initial steps with ploneout and I'd taken ten minutes with pdb inside the __init__() and install() functions (the only two...) in his recipe the pieces fitted together in my head almost instantly. your efforts to figure something out and then document will have a major impact on people understanding this, as per usual. but still, something about it just feels heavy. the idea of having two separate tools, each of which does one thing well, working together to solve a problem suits my sensibilities more than having one more monolithic tool. luckily, we don't really have to convince each other of anything, here. it's entirely possible to have zc.buildout recipes for installing Zope and Plone as well as buildit / workingenv recipes for the same purpose. -r ___ 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 )
[Zope-PAS] roles on the anonymous user
For some environments I need to be able to add a role for people coming from a specific IP address (for example to add a role everyone on campus). At the moment PAS does not support that: roles are determined in the _findUser method but not in _createAnonymousUser. Are there any reasons for not doing that there as well? Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
Re: [Zope] Zope pretends to receive and send XMLRPC data, but strace sees nothing ! (fwd)
On 1/24/07, Maciej Wisniowski [EMAIL PROTECTED] wrote: Another question, do you use ZEO? I know there were some issues with _p_resolveConflict and ZEO (at last in Zope 2.8.x). Result was that with ZEO setup _p_resolveConflict was not called at all. There is solution for this but I don't know if this is your case especially that you are dealing with TemporaryStorage which is typically managed by ZEO Client... If ZEO cannot reach your product (import it), it cannot run any conflict resolution. Make sure that the ZEO server setup has access to those Products that do conflict resolution. -- Martijn Pieters ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] URL referencing
Hello, I've got a script located in /wms/Ccp/Main/TeamLead/Scripts and it needs to reference a workflow object in /wms/Ccp/Main/Workflows/Ccp/ . Currently, we do this by issuing this line : wf = context.Workflows.Ccp.ccp_agro_article But everytime we run this, a username/password prompt comes up, and no matter what we enter (even if we use a Manager account), nothing works. I'm thinking maybe I should refer to the workflow object using a full-path approach. Question is, how ? Do I say : wf = wms.Ccp.Main.Workflows.Ccp.ccp_agro_article ? I tried it and got a global name 'wms' is not defined message. Hope somebody here could shed some light. Regards, Danny ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Adjusting ZODB Pool Size
Hi! We have a very busy site that required zserver-threads to be bumped to 10. My understanding is DB connections (pool_size) is hardwired to 7, no knob to adjust, and it should match the number of zserver-threads. We do get warnings in the logs, so I should fix it. Create a custom_zodb.py and put in your Zope installation directory. Does that mean the zinstance or zeoinstance? The root, or the /etc of the zeoinstance/zinstance? How do I determine the cache_size setting? Right now the Target number of objects in memory per cache 15000. TIA ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Key Error in Catalog Reindex
Dieter, thank you for the suggestion on how to change
\lib\python\OFS\DTMLMethod.py
to avoid the key error.
Before I went ahead and altered zope's the underlying code, I thought I would
try Andres' suggestion first, by rewriting the dtml method as a python script:
REQUEST = container.REQUEST
RESPONSE = REQUEST.RESPONSE
REFERER = REQUEST.get_header('HTTP_REFERER')
catalog = context.Catalog
catalog.manage_catalogReindex(REQUEST, RESPONSE, REFERER)
RESPONSE.redirect(REFERER)
This seems to have fixed the issue. I'll let you know if I notice anything
further.
Thanks kindly,
John T.
-- Original Message --
Date: Mon, 22 Jan 2007 18:01:30 +0100
From: Andreas Jung [EMAIL PROTECTED]
Rewrite the code using a PythonScript and check again for errors.
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] ColdFusion, ASP, etc with Zope/Plone
Murdock wrote: Example: http://www.domain.com/Customer should go to ColdFusion and actual files on the server everything else at http://www.domain.com should feed into Zope I am running Windows Server 2003, IIS6, EnfoldProxy, Latest version of Zope 2. Dunnoy what EnfoldPoxy is or how it works, but put Apache in front of the lot and use its rewrite rules. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Adjusting ZODB Pool Size
On Jan 25, 2007 12:14 PM, Brian wrote: Hi! We have a very busy site that required zserver-threads to be bumped to 10. My understanding is DB connections (pool_size) is hardwired to 7, no knob to adjust, and it should match the number of zserver-threads. We do get warnings in the logs, so I should fix it. Create a custom_zodb.py and put in your Zope installation directory. Does that mean the zinstance or zeoinstance? The root, or the /etc of the zeoinstance/zinstance? How do I determine the cache_size setting? Right now the Target number of objects in memory per cache 15000. TIA hey brian, you are able to adjust both (pool- and cache-size) in the zodb_db-part your zope.conf. Just see the example in my config: 8--snip-8- zodb_db temporary # Temporary storage database (for sessions) temporarystorage name temporary storage for sessioning /temporarystorage mount-point /temp_folder pool-size 8 container-class Products.TemporaryFolder.TemporaryContainer /zodb_db zodb_db zeo.root mount-point / # ZODB cache, in number of objects cache-size 5000 zeoclient server localhost:8100 storage zeo.root name zeo.root var $INSTANCE/var # ZEO client cache, in bytes cache-size 20MB # Uncomment to have a persistent disk cache #client zeo_client0 /zeoclient /zodb_db 8--snip-8- Greets, Patrick ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] URL referencing
snip - Original Message - From: Sinang, Danny To: zope@zope.org Sent: Thursday, January 25, 2007 4:36 AM Subject: [Zope] URL referencing Hello, I've got a script located in /wms/Ccp/Main/TeamLead/Scripts and it needs to reference a workflow object in /wms/Ccp/Main/Workflows/Ccp/ . Currently, we do this by issuing this line : wf = context.Workflows.Ccp.ccp_agro_article But everytime we run this, a username/password prompt comes up, and no matter what we enter (even if we use a Manager account), nothing works. I'm thinking maybe I should refer to the workflow object using a full-path approach. Question is, how ? Do I say : wf = wms.Ccp.Main.Workflows.Ccp.ccp_agro_article I tried it and got a global name 'wms' is not defined message. /snip You may need to set a proxy role on the script that is trying to access the 'ccp_agro_article'. You could also try using Verbose Security to track down your security issue. Jonathan ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] ColdFusion, ASP, etc with Zope/Plone
Thanks for the suggestion, I went to that site and I see that it only works on Unix-Like servers. I don't have any of those available in my environment. Jaroslav Lukesh wrote: - Original Message - From: Murdock [EMAIL PROTECTED] I am implementing a new site using Zope/Plone. This site replaces an old one built in ColdFusion. The problem that I am having is that a portion of our site (Our customer login area) will need to remain on ColdFusion for a while. Is their a method to get most things to Zope/Plone but certain folders to go to ColdFusion. Example: http://www.domain.com/Customer should go to ColdFusion and actual files on the server everything else at http://www.domain.com should feed into Zope Use reverse proxy www.apsis.ch/pound Use directive UrlGroup Customer.* HeadRequire Host www.domain.com.* BackEnd IP#_addr_coldfusion,port#_coldfusion,1 EndGroup ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- View this message in context: http://www.nabble.com/ColdFusion%2C-ASP%2C-etc-with-Zope-Plone-tf3084565.html#a8614876 Sent from the Zope - General mailing list archive at Nabble.com. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] ColdFusion, ASP, etc with Zope/Plone
Can you point me to some good documentation that can get me up and running with Apache quickly, as well as how to use the rewrite rules? Thanks Chris Withers wrote: Murdock wrote: Example: http://www.domain.com/Customer should go to ColdFusion and actual files on the server everything else at http://www.domain.com should feed into Zope I am running Windows Server 2003, IIS6, EnfoldProxy, Latest version of Zope 2. Dunnoy what EnfoldPoxy is or how it works, but put Apache in front of the lot and use its rewrite rules. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- View this message in context: http://www.nabble.com/ColdFusion%2C-ASP%2C-etc-with-Zope-Plone-tf3084565.html#a8614981 Sent from the Zope - General mailing list archive at Nabble.com. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] ColdFusion, ASP, etc with Zope/Plone
- Original Message - From: Murdock [EMAIL PROTECTED] To: zope@zope.org Sent: Thursday, January 25, 2007 8:32 AM Subject: Re: [Zope] ColdFusion, ASP, etc with Zope/Plone Can you point me to some good documentation that can get me up and running with Apache quickly, as well as how to use the rewrite rules? http://httpd.apache.org/docs/2.2/misc/rewriteguide.html Jonathan ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope pretends to receive and send XMLRPC data, but strace sees nothing ! (fwd)
Is _p_resolveConflict method of Inceraser executed at all?
I wonder if traceback you see in console is from the
code you added:
traceback.print_exc(file=stdin)
or it is always shown when there is a conflict error.
code
def _p_resolveConflict(self, old, state1, state2):
print called the _p_resolveConflict of the Increaser object,self
try:
number = max(old,state1,state2)
except Exception,msg:
import traceback
traceback.print_exc(file=sys.stdin)
return max(old, state1, state2)
/code
Yes, The method was not called. However, the traceback was indeed printed by
the print_exc, since there were no tracebacks before I added this line. In
fact, as Gabriel Genellina said :
That might provoke a ConflictError, forcing a
transaction abort and the request to be re-tried (up to three times,
silently, then it goes logged).
as well as Pascal Peregrina:
In general, retry is called when a ZODB Conflict Error has happened.
If I remember well, Zope will silently retry 3 times, and then actually
return an error page showing the Conflict Error.
as the documentation says
http://www.zope.org/Documentation/Books/ZDG/current/ObjectPublishing.stx :
If an unhandled exception is raised during the publishing process, Zope
aborts the transaction. As detailed in Chapter 4. Zope handles
ConflictErrors by re-trying the request up to three times. This is done with
the zpublisher_exception_hook.
Thus, I don't think that the traceback is always shown when there's a
conflict error.
So I decided to look into the file suggested by Maciej Wisniowski :
You may take a look at lib/python/ZODB/ConflictResolution.py
method: tryToResolveConflict. There is a call to _p_resolveConflict.
and edited it like this :
code
def tryToResolveConflict(self, oid, committedSerial, oldSerial, newpickle,
committedData=''):
# class_tuple, old, committed, newstate = ('',''), 0, 0, 0
print in ConflictResolution.py, called the tryToResolveConflict method
with arguments :
print
self,self,oid,oid.__repr__(),committedSerial,committedSerial.__repr__(),oldSerial,oldSerial.__repr__(),newpickle,newpickle.__repr__(),committedData,committedData.__repr__()
try:
prfactory = PersistentReferenceFactory()
file = StringIO(newpickle)
unpickler = Unpickler(file)
unpickler.find_global = find_global
unpickler.persistent_load = prfactory.persistent_load
meta = unpickler.load()
if isinstance(meta, tuple):
klass = meta[0]
newargs = meta[1] or ()
if isinstance(klass, tuple):
klass = find_global(*klass)
else:
klass = meta
newargs = ()
if klass in _unresolvable:
print klass,klass.__repr__,is unresolvable
return None
newstate = unpickler.load()
inst = klass.__new__(klass, *newargs)
try:
resolve = inst._p_resolveConflict
except AttributeError:
print inst.__repr__,has no _p_resolveConflict method
_unresolvable[klass] = 1
return None
old = state(self, oid, oldSerial, prfactory)
committed = state(self, oid, committedSerial, prfactory,
committedData)
resolved = resolve(old, committed, newstate)
file = StringIO()
pickler = Pickler(file,1)
pickler.persistent_id = persistent_id
pickler.dump(meta)
pickler.dump(resolved)
print everything's ok
return file.getvalue(1)
except (ConflictError, BadClassName):
print ConflictError during conflict resolution in tryToResolveConflict,
ConflictResolution.py
import traceback
import sys
traceback.print_exc(file = sys.stdout)
return None
except:
print Exception raised in in tryToResolveConflict,
ConflictResolution.py
import traceback
import sys
traceback.print_exc(file=sys.stdout)
# If anything else went wrong, catch it here and avoid passing an
# arbitrary exception back to the client. The error here will mask
# the original ConflictError. A client can recover from a
# ConflictError, but not necessarily from other errors. But log
# the error so that any problems can be fixed.
logger.error(Unexpected error, exc_info=True)
return None
/code
Now let's see what's going on in the console :
console
in ConflictResolution.py, called the tryToResolveConflict method with
arguments :
self tempstorage.TemporaryStorage.TemporaryStorage instance at 0x43fb6aac
oid '\x00\x00\x00\x00\x00\x00\x00\t' committedSerial
'\x03k#\x93\x1d\xff\xf5\x11' oldSerial '\x03k#\x91^t\xf1D' newpickle '(
cProducts.Transience.Transience\nIncreaser\nq\x01)tq\x02.J\x88\xa6\xb8E.'
committedData ''
ConflictError during conflict resolution in tryToResolveConflict,
ConflictResolution.py
Traceback (most recent call last):
File /opt/aef/Zope-2.9.0/lib/python/ZODB/ConflictResolution.py, line
126, in tryToResolveConflict
old = state(self,
Re: [Zope] Zope pretends to receive and send XMLRPC data, but strace sees nothing ! (fwd)
Concerning zeo, I do not use it in the developpement plateforme, but there's
one in the test and production platformes, so maybe I will face the problem
during the test phase.
I do not understand : session objects should be unique for each browser, so
why are there conflict errors on them ?
If ZEO cannot reach your product (import it), it cannot run any
conflict resolution. Make sure that the ZEO server setup has access to
those Products that do conflict resolution.
The product that does conflict resolution is the Transient object (I think
it is the session object) , which is Zope2.9.0/lib/python/Products/Transcience.
I think that zeo should see it.
2007/1/25, yacine chaouche [EMAIL PROTECTED]:
Is _p_resolveConflict method of Inceraser executed at all?
I wonder if traceback you see in console is from the
code you added:
traceback.print_exc(file=stdin)
or it is always shown when there is a conflict error.
code
def _p_resolveConflict(self, old, state1, state2):
print called the _p_resolveConflict of the Increaser object,self
try:
number = max(old,state1,state2)
except Exception,msg:
import traceback
traceback.print_exc(file=sys.stdin)
return max(old, state1, state2)
/code
Yes, The method was not called. However, the traceback was indeed printed
by the print_exc, since there were no tracebacks before I added this line.
In fact, as Gabriel Genellina said :
That might provoke a ConflictError, forcing a
transaction abort and the request to be re-tried (up to three times,
silently, then it goes logged).
as well as Pascal Peregrina:
In general, retry is called when a ZODB Conflict Error has happened.
If I remember well, Zope will silently retry 3 times, and then actually
return an error page showing the Conflict Error.
as the documentation says
http://www.zope.org/Documentation/Books/ZDG/current/ObjectPublishing.stx :
If an unhandled exception is raised during the publishing process, Zope
aborts the transaction. As detailed in Chapter 4. Zope handles
ConflictErrors by re-trying the request up to three times. This is done with
the zpublisher_exception_hook.
Thus, I don't think that the traceback is always shown when there's a
conflict error.
So I decided to look into the file suggested by Maciej Wisniowski :
You may take a look at lib/python/ZODB/ConflictResolution.py
method: tryToResolveConflict. There is a call to _p_resolveConflict.
and edited it like this :
code
def tryToResolveConflict(self, oid, committedSerial, oldSerial, newpickle,
committedData=''):
# class_tuple, old, committed, newstate = ('',''), 0, 0, 0
print in ConflictResolution.py, called the tryToResolveConflict
method with arguments :
print
self,self,oid,oid.__repr__(),committedSerial,committedSerial.__repr__(),oldSerial,oldSerial.__repr__(),newpickle,newpickle.__repr__(),committedData,committedData.__repr__()
try:
prfactory = PersistentReferenceFactory()
file = StringIO(newpickle)
unpickler = Unpickler(file)
unpickler.find_global = find_global
unpickler.persistent_load = prfactory.persistent_load
meta = unpickler.load()
if isinstance(meta, tuple):
klass = meta[0]
newargs = meta[1] or ()
if isinstance(klass, tuple):
klass = find_global(*klass)
else:
klass = meta
newargs = ()
if klass in _unresolvable:
print klass,klass.__repr__,is unresolvable
return None
newstate = unpickler.load()
inst = klass.__new__(klass, *newargs)
try:
resolve = inst._p_resolveConflict
except AttributeError:
print inst.__repr__,has no _p_resolveConflict method
_unresolvable[klass] = 1
return None
old = state(self, oid, oldSerial, prfactory)
committed = state(self, oid, committedSerial, prfactory,
committedData)
resolved = resolve(old, committed, newstate)
file = StringIO()
pickler = Pickler(file,1)
pickler.persistent_id = persistent_id
pickler.dump(meta)
pickler.dump(resolved)
print everything's ok
return file.getvalue(1)
except (ConflictError, BadClassName):
print ConflictError during conflict resolution in
tryToResolveConflict, ConflictResolution.py
import traceback
import sys
traceback.print_exc(file = sys.stdout)
return None
except:
print Exception raised in in tryToResolveConflict,
ConflictResolution.py
import traceback
import sys
traceback.print_exc(file=sys.stdout)
# If anything else went wrong, catch it here and avoid passing an
# arbitrary exception back to the client. The error here will
mask
# the original ConflictError. A client can recover from a
# ConflictError, but not necessarily from other errors. But log
# the error so that any
[Zope] Session Timeout Troubles
Hi, We're using Zope 2.8.8 with a bunch of client sites set up in various sub directories / databases. We're using ZEO for the database storage and a local zodb file for the temporary data. I've recently been asked to set the system to user sessions time out after 15 minutes of activity. I've changed the setting in our zope.conf file (the session timeout value) and restarted zope. However, if I open a page on the site that requires logon and log in, then leave the browser alone for 15 or 20 minutes or even an hour, when I click on a link, it doesn't force me to re-authenticate... it just works as normal. I'm hoping someone could tell me if there's other stuff I need to do to make the session time out and force reauthentication at the server level (rather than having to add code to every user site, as we have over 500 different ones and I'm not sure there's something common enough for me to hook into if I have to alter code on the sites themselves to enable this. It's okay if I get back a response that it can't be done, but I have to be able to provide my boss with a difinitive answer. Thank You, Robin Sale = Robin Sale, Software Engineer Specialized Technology Resources, Inc. 10 Water Street Enfield CT 06082-4899 USA [EMAIL PROTECTED] ICQ: 190327116 +1 860 749-8371 Ext. 336 Telephone +1 860 749-9158 Fax ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Session Timeout Troubles
--On 25. Januar 2007 09:59:44 -0500 Sale, Robin [EMAIL PROTECTED] wrote: Hi, We're using Zope 2.8.8 with a bunch of client sites set up in various sub directories / databases. We're using ZEO for the database storage and a local zodb file for the temporary data. I've recently been asked to set the system to user sessions time out after 15 minutes of activity. I've changed the setting in our zope.conf file (the session timeout value) and restarted zope. However, if I open a page on the site that requires logon and log in, then leave the browser alone for 15 or 20 minutes or even an hour, when I click on a link, it doesn't force me to re-authenticate... it just works as normal. You can configure the session timeout and the max. number of session objects. Perhaps you have more user sessions than configured so some sessions might be deleted before the timeout? Andreas pgpojYAhuhhIK.pgp Description: PGP signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] ColdFusion, ASP, etc with Zope/Plone
Murdock wrote: Anyone know of any good open source or very low cost Reverse Proxies that will run on Windows Server? Please trim your replies. Apache is what you're looking for. You've been pointed at the docs, further help can be found on #apache on irc.freenode.net cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
RE: [Zope] Session Timeout Troubles
Andreas, thank you for replying. Actually, the problem I have is the reverse - the sessions NEVER seem to time out. I have a directive from up on high to make it so that 15 minutes of inactivity within any location on the site (All of which is password protected under acl_users or acl_users(group aware) setup.) It seems like no matter what I do to the session-timeout-minutes value in zope.conf, as long as the user keeps their browser open, they can continue to use the site even if they are idle for an hour or more... I have the session-timeout-minutes set to 15 and have set the session-resolution-seconds value to 20 seconds as well and restarted Zope and yet it seems to not make a difference. Thank you, Robin = Robin Sale, Software Engineer Specialized Technology Resources, Inc. 10 Water Street Enfield CT 06082-4899 USA [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Jung Sent: Thursday, January 25, 2007 10:08 AM To: Sale, Robin; zope@zope.org Subject: Re: [Zope] Session Timeout Troubles --On 25. Januar 2007 09:59:44 -0500 Sale, Robin [EMAIL PROTECTED] wrote: Hi, We're using Zope 2.8.8 with a bunch of client sites set up in various sub directories / databases. We're using ZEO for the database storage and a local zodb file for the temporary data. I've recently been asked to set the system to user sessions time out after 15 minutes of activity. I've changed the setting in our zope.conf file (the session timeout value) and restarted zope. However, if I open a page on the site that requires logon and log in, then leave the browser alone for 15 or 20 minutes or even an hour, when I click on a link, it doesn't force me to re-authenticate... it just works as normal. You can configure the session timeout and the max. number of session objects. Perhaps you have more user sessions than configured so some sessions might be deleted before the timeout? Andreas ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: ColdFusion, ASP, etc with Zope/Plone
Is their a method to get most things to Zope/Plone but certain folders to go to ColdFusion. Does ColdFusion have an API which can be called from Python or Perl? Does it have an XML-RPC, SOAP or other web API interface? If so then you could write a Zope External Method in Python or Perl that runs ColdFusion using the latter's API. You will be able to pass in the parameters that you need from Zope, and return ColdFusion output to display in Zope. For instance, I run a simple example of this approach at http://jonathanmark.com:8080/Cheetah/callUseCheetah on a Zope 2.10 server. the Zope Python Script callUseCheetah acquires the names of members of the Byrds rock group. It acquires these names from a lines property of the Zope folder Cheetah. (Cheetah is not just a folder name, it is also the name of a Python templating engine.) callUseCheetah then calls the Zope External Method useCheetah to render the output. The template engine Cheetah returns the rendered page to Zope which displays the names in the title of the page. Here is the the Zope Python Script callUseCheetah: # code to get 'htmlpage' goes here... htmlpage = context.html # now extract the body body = context.useCheetah(htmlpage, context.name) # now do something with 'body' ... print body return printed ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] [ANN] Zope 2.10.2 released
The Zope developer community I is pleased to announce the release of Zope 2.10.2. You can download Zope 2.10.2 from: http://www.zope.org/Products/Zope/2.10.2/ This release uses unicode as internal representation for ZPT. For this reason you are strongly encouraged to read http://www.zope.org/Products/Zope/2.10.2b1/Zope-2.10.2_released carefully. Some new features of Zope 2.10: - ZPT implementation based on Zope 3 - experimental WSGI and Twisted integration - Zope 3.3, Five 1.5 integration - clock server - lots of minor improvements and fixes - replaced several Zope 2 modules with their sister implementation of Zope 3 For more information on what is new in this release, see the CHANGES.txt files for the release: http://www.zope.org/Products/Zope/2.10.2/CHANGES.txt Please bring all the bugs you have found to the Zope bugtracker: http://collector.zope.org/Zope For more information on the available Zope releases, guidance for selecting the right distribution and installation instructions, please see: http://www.plope.com/Books/2_7Edition/InstallingZope.stx Supported Python versions: Zope 2.10 requires Python 2.4.3+ (Python 2.4.2 is still acceptable). Older Python versions are no longer supported. Using Python 2.5 is also *unsupported*. - -- Andreas Jung -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope Plone development, Consulting pgpCk2GVjcCFn.pgp Description: PGP signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope pretends to receive and send XMLRPC data, but strace sees nothing ! (fwd)
yacine chaouche wrote at 2007-1-24 18:23 +0100: As Gabriel Genellina said earlier in this discussion, the probleme could come from the dicoLignes variable that is stored in the session.I don't get it, the exception says that the Increaser object is responsible of the conflict error : ZODB.POSException.ConflictError database conflict error (oid 0x09, class Products.Transience.Transience.Increaser, serial this txn started with 0x036b192256c66688 2007-01-23 16:34:20.337891, serial currently committed 0x036b19236a4be0ee 2007-01-23 16:35:24.913219) But the Increaser class has a _p_resolveConflict method : In order to resolve a conflict, the storage must have sufficient history to deliver the old state. A TemporaryStorage has only a very limited history -- way to often not enough for conflict resolution. -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Allow import of whole filesystem class hierarchy?
Kirk Strauser wrote at 2007-1-24 13:16 -0600: ... Before I start on such an adventure, what is the Python/Zope term for what I'm trying to do, specifically to allow the import of an entire module, including classes inside it, and methods inside those classes' objects? With allow_module you allow import of a (single) module and make all its content (on top level!) public (i.e. usable). With allow_class, you make all its content (on top level) public. With allow_type, you make a built in type usable in untrusted code. That's what you have as prepared tools. Adventures are necessary to get more of it -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Session Timeout Troubles
Sale, Robin wrote at 2007-1-25 09:59 -0500: ... I've recently been asked to set the system to user sessions time out after 15 minutes of activity. I've changed the setting in our zope.conf file (the session timeout value) and restarted zope. However, if I open a page on the site that requires logon and log in, then leave the browser alone for 15 or 20 minutes or even an hour, when I click on a link, it doesn't force me to re-authenticate... it just works as normal. I have never heard of such a behaviour -- and it is almost unbelievable. In any such case (unbelievable behaviour), I always use a powerfull tool (the debugger in this case) to shed light into the behaviour. -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
RE: [Zope] Session Timeout Troubles
Dieter, Thank you for your reply. Originally was a customer-driven need to have them as long as possible for some time, but now there is a management need to make sessions as short as possible to increase security. My big concern is that my predecessor may have done some serious deep-down hacking to make sessions not time out until the browser is closed to stop the whining. He's not around anymore and I'm not as much of an expert as him. What I'm doing: Visit a simple HTML page that has a link to a second ... all of which is contained within a folder that requires authenticated user to view. I go to server:8080/page_path/page_name and have to log in. I do so, and see the page. Now, I wait 20,30, 45 minutes, even an hour and click on the link to server:8080/page_path/page_name2. What I WANT to happen is to be forced to provide my credentials if it's been sitting longer than 15 minutes. What IS happening is that I simply get the page. The zope.conf is set with a session-timeout-minutes 15. I've looked at the debugging page in the control panel, but it doesn't tell me anything I recognize as useful. = Robin Sale, Software Engineer Specialized Technology Resources, Inc. 10 Water Street Enfield CT 06082-4899 USA [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dieter Maurer Sent: Thursday, January 25, 2007 1:28 PM To: Sale, Robin Cc: zope@zope.org Subject: Re: [Zope] Session Timeout Troubles Sale, Robin wrote at 2007-1-25 09:59 -0500: ... I've recently been asked to set the system to user sessions time out after 15 minutes of activity. I've changed the setting in our zope.conf file (the session timeout value) and restarted zope. However, if I open a page on the site that requires logon and log in, then leave the browser alone for 15 or 20 minutes or even an hour, when I click on a link, it doesn't force me to re-authenticate... it just works as normal. I have never heard of such a behaviour -- and it is almost unbelievable. In any such case (unbelievable behaviour), I always use a powerfull tool (the debugger in this case) to shed light into the behaviour. -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Captcha Image For Form Verification
Does anyone if there is a product (specifically for zope) for creating a captcha image to verify that an actual human is submitting a form? I am using zope 2.8.1 with python 2.3.5 on a windows server. I am currently looking into this: http://captchas.net/sample/python/ ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] sorting
I'd like to sort the items in a folder by relevance, relevance being a
property I've assigned.
I'm using a python script
for aj in ao.objectItems(items):
aao=aj[1] #the object
title=aao.title
id=aj[0]
aanum=len(aao.objectIds())
if ( aanum 1 ):
if (title != '' and id != 'index_html' and not
o.hasProperty('display')):
ret=ret # + li id=ul_+id+
else:
if (title != '' and id != 'index_html' and not
o.hasProperty('display')):
ret=ret # + li id=ul_+id+ class=closed1
if (title != '' and id != 'index_html' and not
o.hasProperty('display')):
ret=ret+li id=ul_+id+h3a
href=\+aao.absolute_url()+\nbsp;nbsp;nbsp;+title+/a/h3/li\n
.
When I try
values=ao.objectItems(items)
values.sort(lambda a,b: cmp(a[0],b[0]))
for aj in values:
aao=aj[1] #the object
title=aao.title
Error Type: AttributeError
Error Value: 'tuple' object has no attribute 'sort'
Obviously, id isn't really what I wanted to sort by anyway but since I can't
even do that I can't really go on to try to
use getattr to try and sort on relevance..
Kate
The full trackback in case anyone wants it is..
Traceback (innermost last):
Module ZPublisher.Publish, line 115, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 41, in call_object
Module OFS.DTMLDocument, line 128, in __call__
- DTMLDocument at /kfplsite/redesign/aboutLibrary/index_html
- URL:
http://www2.kfpl.ca:8080/kfplsite/redesign/aboutLibrary/index_html/manage_ma
in
- Physical Path: /kfplsite/redesign/aboutLibrary/index_html
Module DocumentTemplate.DT_String, line 476, in __call__
Module OFS.DTMLDocument, line 121, in __call__
- DTMLDocument at /kfplsite/redesign/menuLeft used for
/kfplsite/redesign/aboutLibrary
- URL: http://www2.kfpl.ca:8080/kfplsite/redesign/menuLeft/manage_main
- Physical Path: /kfplsite/redesign/menuLeft
Module DocumentTemplate.DT_String, line 476, in __call__
Module OFS.DTMLMethod, line 137, in __call__
- DTMLMethod at /kfplsite/redesign/pythonLeftMenu used for
/kfplsite/redesign/menuLeft
- URL:
http://www2.kfpl.ca:8080/kfplsite/redesign/pythonLeftMenu/manage_main
- Physical Path: /kfplsite/redesign/pythonLeftMenu
Module DocumentTemplate.DT_String, line 476, in __call__
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: redesign
Module string, line 1, in expression
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module Products.PythonScripts.PythonScript, line 323, in _exec
Module None, line 65, in pythonLeftMenuKatie2
- PythonScript at /kfplsite/redesign/pythonLeftMenuKatie2 used for
/kfplsite/redesign/menuLeft
- Line 65
AttributeError: 'tuple' object has no attribute 'sort'
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] sorting
--On 25. Januar 2007 15:03:19 -0500 Kate Legere [EMAIL PROTECTED] wrote: values=ao.objectItems(items) values.sort(lambda a,b: cmp(a[0],b[0])) Error Type: AttributeError Error Value: 'tuple' object has no attribute 'sort' This error message is self-explaining. You can only sort lists, not tuples. Obviously, id isn't really what I wanted to sort by anyway but since I can't even do that I can't really go on to try to Look at the 'sequence' module and the 'sequence.sort' method as documented in the Zope Book 2.7 Edition. -aj pgpFjiNhysTd5.pgp Description: PGP signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Session Timeout Troubles
I've looked at the debugging page in the control panel, but it doesn't tell me anything I recognize as useful. Are you sure that your authentication uses session? Maybe it uses cookies? Try to set variable in the session on one page and display this on the other one. Then wait for 15-20 minutes and see what happens. Another thing that may cause this is session-resolution-seconds setting in your zope.conf - this affect session timeout value. -- Maciej Wisniowski ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Captcha Image For Form Verification
Does anyone if there is a product (specifically for zope) for creating a captcha image to verify that an actual human is submitting a form? I am using zope 2.8.1 with python 2.3.5 on a windows server. I am currently looking into this: http://captchas.net/sample/python/ AFAIK there is such product for Plone, you may want to take a look at this. -- Maciej Wisniowski ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
RE: [Zope] Session Timeout Troubles
Thank you for your reply. I'm guessing that yes, Zope is using session cookies in this setup. Unfortunately, the people who did the original configuration and setup are no longer with my company, so I can't ask directly. How would I be able to tell if it's set one way or another? I certainly see nothing about cookie auth in the zope.conf file. (I'm hitting the Zope server directly (not going through our Apache front-end) to make sure I'm only dealing with a Zope issue. Thanks Again, Robin = Robin Sale, Software Engineer Specialized Technology Resources, Inc. 10 Water Street Enfield CT 06082-4899 USA [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej Wisniowski Sent: Thursday, January 25, 2007 3:22 PM To: Sale, Robin Cc: zope@zope.org Subject: Re: [Zope] Session Timeout Troubles I've looked at the debugging page in the control panel, but it doesn't tell me anything I recognize as useful. Are you sure that your authentication uses session? Maybe it uses cookies? Try to set variable in the session on one page and display this on the other one. Then wait for 15-20 minutes and see what happens. Another thing that may cause this is session-resolution-seconds setting in your zope.conf - this affect session timeout value. -- Maciej Wisniowski ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Session Timeout Troubles
I'm guessing that yes, Zope is using session cookies in this setup. Unfortunately, the people who did the original configuration and setup are no longer with my company, so I can't ask directly. How would I be able to tell if it's set one way or another? I certainly see nothing about cookie auth in the zope.conf file. This is done by your acl_users. I don't know what kind of User folder you're using. You may see this by going to acl_users folder in ZMI and on the top you should see something like: 'Pluggable User Folder at /path/to/acl_users' where 'pluggable user folder' is name of your acl_users product. Depending of what UserFolder (acl_users) you use it may be (or may not be) possible to configure it to not to use cookies. Another solution might be to use session hooks (script that is called when user session expires) to logout the user or you may use different UserFolder, eg. PAS. -- Maciej Wisniowski ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] ColdFusion, ASP, etc with Zope/Plone
from scratch without google/sf/fm :o) 1. pound with linux and colinux kernel runtime on windows 2. pound with linux under vmware or old pre-M$ virtualPC on windows 3. pound under cygwin on windows 4. squid under windows 5. apache under windows 6. IIS - M$ ISA (?) - Original Message - From: Murdock [EMAIL PROTECTED] Anyone know of any good open source or very low cost Reverse Proxies that will run on Windows Server? ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Migrating to Zope 2.10.1 breaks unrestrictedTraverse
I'm trying to get an object by walking a path. Previously, I used baseobject.unrestrictedTraverse(path). Upon migrating to 2.10.1, though, doing the same thing often produces the following error: File /usr/local/zenoss/Products/ZenModel/Organizer.py, line 148, in getOrganizer return self.getDmdRoot(self.dmdRootName).unrestrictedTraverse(path) File usr/local/zenoss/lib/python/OFS/Traversable.py, line 259, in unrestrictedTraverse AttributeError: REQUEST The problem appears to be that the Traversable mixin assumes that self.REQUEST will be available; since we're calling it from outside Zope, though, there is no request. Any thoughts? Why was this changed, and is there an extant way to get the same result without just writing a simple method that walks the path? Thanks, Ian McCracken ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] ColdFusion, ASP, etc with Zope/Plone
On Thu, Jan 25, 2007 at 05:31:28AM -0800, Murdock wrote: Thanks for the suggestion, I went to that site and I see that it only works on Unix-Like servers. I don't have any of those available in my environment. you could run vmware and put a linux instance there. Jaroslav Lukesh wrote: - Original Message - From: Murdock [EMAIL PROTECTED] I am implementing a new site using Zope/Plone. This site replaces an old one built in ColdFusion. The problem that I am having is that a portion of our site (Our customer login area) will need to remain on ColdFusion for a while. Is their a method to get most things to Zope/Plone but certain folders to go to ColdFusion. Example: http://www.domain.com/Customer should go to ColdFusion and actual files on the server everything else at http://www.domain.com should feed into Zope Use reverse proxy www.apsis.ch/pound Use directive UrlGroup Customer.* HeadRequire Host www.domain.com.* BackEnd IP#_addr_coldfusion,port#_coldfusion,1 EndGroup ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- View this message in context: http://www.nabble.com/ColdFusion%2C-ASP%2C-etc-with-Zope-Plone-tf3084565.html#a8614876 Sent from the Zope - General mailing list archive at Nabble.com. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- David Bear phone: 602-496-0424 fax:602-496-0955 College of Public Programs/ASU University Center Rm 622 411 N Central Phoenix, AZ 85007-0685 Beware the IP portfolio, everyone will be suspect of trespassing ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Migrating to Zope 2.10.1 breaks unrestrictedTraverse
--On 25. Januar 2007 16:12:01 -0500 Ian McCracken [EMAIL PROTECTED] wrote: I'm trying to get an object by walking a path. Previously, I used baseobject.unrestrictedTraverse(path). Upon migrating to 2.10.1, though, doing the same thing often produces the following error: Migrating from which version? Provide a unittest that demonstrates the behavior on bare Zope installation. -aj pgpxaBq33TYIS.pgp Description: PGP signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: [Zope-Annce] [ANN] Zope 2.10.2 released
--On 25. Januar 2007 18:37:03 +0100 Andreas Jung [EMAIL PROTECTED] wrote: The Zope developer community I is pleased to announce the release of Zope 2.10.2. You can download Zope 2.10.2 from: http://www.zope.org/Products/Zope/2.10.2/ This release uses unicode as internal representation for ZPT. For this reason you are strongly encouraged to read http://www.zope.org/Products/Zope/2.10.2b1/Zope-2.10.2_released carefully. Sorry for posting a broken link. The correct one is: http://www.zope.org/Products/Zope/2.10.2/Zope-2.10.2-released Andreas pgp3Mnr1H1RKr.pgp Description: PGP signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-DB] modifications on a query
--On 26. Januar 2007 07:37:25 + Graziella Toutoungis [EMAIL PROTECTED] wrote: Hello, I use zope2.9.4 with postgresql8.1, in my database i have some tables are the result of a query on other tables. exe: table1 is the result of table2 with table3 My user can connect to the database and he can modify the table1, this modification should done on the orginals tables table2 and table3 my problem is how i can specify the origin of the column in table for verifing that table2 and table3 may this modifications? Please rephrase your question and point out the Zope specific part of the question. -aj pgpcXrKPpMCqG.pgp Description: PGP signature ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
