Re: [Zope-dev] IRC discussion about testing
* Jim Fulton j...@zope.com [2009-08-12 20:56]: This seems heavier than needed. Also, if someone extends this, they're going to get an awful lot of sections that might have names that conflict with names in their buildout. I do like the fact that the versions section is reusable. :) Here's an alternative: [versions] zope.foo = 1.2.3 zope.bar = 1.2.3 zope.app.baz = 1.2.3 grok.bar = 1.1.0 thirdparty.dependency = 4.4 [ztk] projects = zope.foo zope.bar zope.app.baz also-tested = grok.bar Yup, that looks much better. As far as I'm concerned, let's use this. (I'll leave it to Martijn to explain whether/which/why additional information should be stored in the KGS in computer-readable form.) I've just updated z3c.recipe.compattest to support exactly this: [buildout] parts = ztk-tests extends = the-file-above [ztk-tests] recipe = z3c.recipe.compattest include = ${ztk:projects} ${ztk:also-tested} Would you give it a try? Wolfgang ___ 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] List of packages in ZTK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 08/11/2009 11:39 PM, Jim Fulton wrote: On Sat, Jul 4, 2009 at 7:33 AM, Christian Theunec...@gocept.com wrote: Hi, I took the Zope 3.4 KGS, removed the obvious packages that do not belong to the ZTK out of the list and created a home for the master list that defines which packages belong to the ZTK. It's in the Zope toolkit documentation: http://docs.zope.org/zopetoolkit/about/packages.html So, if you see that a package is missing or is classified in the wrong way, then please speak up. Why is zope.ucol in the list? It's a pain to install (and thus test) because it needs ICU. It is in there because I started that list from an inclusive point of view, removing things that shouldn't be in there. I'll take zope.ucol out. Christian - -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqDtXUACgkQdUt9X/gknwLN4gCg1ecUazuNgxeU14nz7Irohxo3 aVEAn0Ie0FTN+ECSkAHjXAPI3KgLMTEO =D+qJ -END PGP SIGNATURE- ___ 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] MailHost Improvements
On Aug 13, 2009, at 5:12, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 for the approach in general (I haven't looked at the patch in detail). Assuming all tests pass, and that you have a test exercising the ':' bug you describe, I would just commit it on the trunk (I think such a change should be in the upcoming 2.12 beta). +1 for the approach and for adding it to 2.12 if it is backwards- compatible. jens ___ 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] For the record - a minimum changes to zope.proxy to support zope.deferredimport under google app engine
I am a !...@head ;-) Forgot the else: clause in the code I posted. Corrected code is below. T On Thu, Aug 13, 2009 at 11:30 AM, Tim Hoffman t...@zute.net wrote: Hi Folks This is a quick and dirty change and to be honest the main reason I am posting it here is so there is a searchable record for anyone else who wants to use zope.deferredimport under google app engine. (With some content models zope.deferredimport is a great way of dealing with cyclic dependancies and possibly improving startup times - see bottom of this email.) Below is a minimal set of changes to zope.proxy.__init__ that is required so that zope.deferredimport can be used. It does mean you need peak.utils to implement a basic proxy. incorrect code shown, Should have read try: from zope.proxy._zope_proxy_proxy import * from zope.proxy._zope_proxy_proxy import _CAPI except NotImplementedError: pass else: from peak.util.proxies import ObjectProxy class ProxyBase(ObjectProxy): pass def getProxiedObject(obj): if hasattr(obj,'__subject__'): return obj.__subject__ else: return obj def removeAllProxies(obj): return getProxiedObject(obj) def sameProxiedObjects(obj1,obj2): if getProxiedObject(obj1) == getProxiedObject(obj2): return True else: return False There are a couple of other zope.proxy functions from the 'c' api that I haven't looked at yet as they aren't used by zope.deferredimport. Suggestions on improving it and/or followups on the other functions would also be welcome. I have also found that deferred import can help with app engine startup times as it means you can import a module you depend on but not really import the code until it gets touched which can allow you to stagger you startup costs. (For instance edit functionality of a site could be deferred until someone actually edits something). Hope this helps someone Regards Tim Hoffman ___ 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] [Zope 2.11+] '-C' key in REQUEST.form
I just came across the fact that an empty REQUEST contains a key-value pair '-C : '' in REQUEST.form. Does anyone know where this is coming from? Andreas -- ZOPYX Ltd. Co KG \ ZOPYX Friends Charlottenstr. 37/1 \ The experts for your Python, Zope and D-72070 Tübingen \ Plone projects www.zopyx.com, i...@zopyx.com \ www.zopyx.de/friends, frie...@zopyx.de E-Publishing, Python, Zope Plone development, Consulting begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ 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] [Zope 2.11+] '-C' key in REQUEST.form
I don't know where it is coming, but I have seen it in Zope 2.10 as well. -Tom Andreas Jung wrote: I just came across the fact that an empty REQUEST contains a key-value pair '-C : '' in REQUEST.form. Does anyone know where this is coming from? Andreas ___ 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 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] Working KGS tool! (was Re: IRC discussion about testing)
On Thu, Aug 13, 2009 at 2:26 AM, Wolfgang Schnerringw...@gocept.com wrote: * Jim Fulton j...@zope.com [2009-08-12 20:56]: ... Here's an alternative: [versions] zope.foo = 1.2.3 zope.bar = 1.2.3 zope.app.baz = 1.2.3 grok.bar = 1.1.0 thirdparty.dependency = 4.4 [ztk] projects = zope.foo zope.bar zope.app.baz also-tested = grok.bar Yup, that looks much better. As far as I'm concerned, let's use this. (I'll leave it to Martijn to explain whether/which/why additional information should be stored in the KGS in computer-readable form.) I've just updated z3c.recipe.compattest to support exactly this: ... Would you give it a try? Yup. Works great. I've updated: svn://svn.zope.org/repos/main/zopetoolkit/branches/jim-kgs/kgs to use it. I created ztk.cfg that looks like: [ztk] libraries = ... under-review = ... projects = ${ztk:libraries} ${ztk:under-review} [buildout] versions = versions allow-picked-versions = false [versions] ... and a buildout.cfg: [buildout] parts = test-ztk extends = ztk.cfg [test-ztk] recipe = z3c.recipe.compattest include = ${ztk:projects} This gives me the test files I expect that use the specified versions. One minor quibble is that the recipe uses the part name as a test file prefix for the individual tests (e.g. test-ztk-zope.proxy). But the combined test runner has test- in front of the part name, so I get test-test-ztk. I'd like to use the part name for the combined test name, test-ztk. Thanks. Thanks too to Fabio for helping to move this forward! So, I think we now have a tool that will let us take the next steps. Can we all agree on this? Jim -- Jim Fulton ___ 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] Zope Tests: 7 OK
Summary of messages to the zope-tests list. Period Wed Aug 12 12:00:00 2009 UTC to Thu Aug 13 12:00:00 2009 UTC. There were 7 messages: 7 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Wed Aug 12 20:53:22 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012281.html Subject: OK : Zope-2.12 Python-2.4.6 : Linux From: Zope Tests Date: Wed Aug 12 20:57:22 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012282.html Subject: OK : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Wed Aug 12 20:59:22 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012283.html Subject: OK : Zope-2.12-alltests Python-2.4.6 : Linux From: Zope Tests Date: Wed Aug 12 21:01:22 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012284.html Subject: OK : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Wed Aug 12 21:03:22 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012285.html Subject: OK : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Wed Aug 12 21:05:22 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012286.html Subject: OK : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Wed Aug 12 21:07:22 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012287.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] Working KGS tool! (was Re: IRC discussion about testing)
Hello, * 2009-08-13 13:06, Jim Fulton wrote: So, I think we now have a tool that will let us take the next steps. Can we all agree on this? Yey, great! I will update my buildbot instance to use this system. Fabio ___ 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] IRC discussion about testing
On Wednesday 12 August 2009, Jim Fulton wrote: I'm not sure why this all has to be computer readable. What is the use case for computer readable knowledge of whether a package is in the kgs or just used to test it? What is the need for computer readable information about where the package is being developed. We can use such a list to extract more information from included packages. For example, I have a script to extract all CHANGES.txt entries in comparison to an older KGS version. Thus, knowing the list of packages that we consider part of the KGS is very useful beyond testing, for example release management. Regards, Stephan PS: I am still in Germany but will be back home late Sunday to read discussions more carefully. -- Entrepreneur and Software Geek Google me. Zope Stephan Richter ___ 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] KGS trunk without failures
On Friday 07 August 2009, Fabio Tranchitella wrote: If somebody tells me how it is possible to get projects from the controlled-packages.cfg using zope.kgs, I can modify the recipe code to understand it. :) I did not use the precise jargon; read project wherever I write about packages in the zope.kgs and zope.release packages. Regards, Stephan -- Entrepreneur and Software Geek Google me. Zope Stephan Richter ___ 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] MailHost Improvements
On Wed, Aug 12, 2009 at 9:42 PM, Andreas Jungli...@zopyx.com wrote: On 13.08.09 01:03, Alec Mitchell wrote: Hello, I've been working on making Plone use the standard Zope MailHost in place of the custom Products.SecureMailHost we've been using since Plone 2.1 (See: http://dev.plone.org/plone/ticket/8814). During this process I've run into a couple bugs in the MailHost implementation and I believe it is missing some essential functionality. The most significant issue is that if you call send() with a messageText containing just the message body, and that body has a ':' in it (e.g. a url) the body will be treated as a header and you'll send a nonsense message. The current implementation of send() also puts a fairly large burden on developers who want to generate simple, correctly encoded messages. Finally, send() relies heavily on the long deprecated 'rfc822' and 'mimetools' modules which have been removed from Python 3.0. I've attached a patch that updates MailHost to use the 'email' module for parsing and generating messages. In addition to fixing the issues that I ran across, and maintaining compatibility, it provides a number of new features: * send and sendTemplate accept an optional charset argument. Using this will set the content-type charset, as well as trigger appropriate encoding if needed. * send and sendTemplate accept an optional msg_type argument which will set the content type header for the message. * The messageText, mfrom, mto, and subject arguments may now be unicode or encoded non-ascii strings, provided a charset is given. Any unicode input will be automatically encoded to the provided charset (or the default charset). Headers will be further encoded in compliance with rfc2822. The message body will be further encoded using a transfer encoding determined by the email.Charset registry (e.g. 7bit for us-ascii, quoted-printable for utf-8 and iso8859, base64 for most other encodings). * The messageText argument now accepts email.Message.Message objects directly. I'm attaching a patch that includes these changes as well as tests for all new functionality. I hope to integrate these changes into Zope 2.12 before final release, but would like to hear the opinions of Zope developers before committing. Though these are fairly significant changes, I believe they provide very useful functionality as well as at least one critical fix, while maintaining 100% compatibility. This comes very, very late. We are pretty close to a release. Please put the changes on the trunk only. We will check after my vacation if we can move it into the 2.12 beta. I've put my latest changes on Zope trunk. All the existing tests pass (with a couple essentially cosmetic modifications in the MailHost tests), and there are 14 new tests which verify both existing and new functionality, as well as the fixed bugs. The new behavior should be identical to the existing behavior when the new charset and msg_type parameters aren't used, with the following exceptions: 1) Passing a message body containing a ':' no longer produces a nonsense email. 2) Providing unicode strings for the text or headers no longer results in a garbage message (it may produce a UnicodeEncodeError though). 3) 8bit (encoded) strings provided as headers will be converted to 7bit, using encoding determined in messageText headers or the default encoding. It would be very helpful to have these changes in Zope 2.12; otherwise, Plone 4.0 will be stuck with our unmaintained SecureMailHost product for yet another release in order to provide equivalent functionality. Moving to a standard Zope MailHost would be a big benefit for Plone, and all Zope users will benefit from the ability to easily send properly formed non-ASCII messages. Alec P.S. Andreas, if there's an address where I can send some nice wine to help facilitate the merge into 2.12, let me know ;-) ___ 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 )