[Zope-dev] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Fri Aug 14 12:00:00 2009 UTC to Sat Aug 15 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Fri Aug 14 20:46:35 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012296.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Fri Aug 14 20:48:35 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012297.html Subject: OK : Zope-2.12 Python-2.4.6 : Linux From: Zope Tests Date: Fri Aug 14 20:50:35 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012298.html Subject: OK : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Fri Aug 14 20:52:40 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012299.html Subject: OK : Zope-2.12-alltests Python-2.4.6 : Linux From: Zope Tests Date: Fri Aug 14 20:54:40 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012300.html Subject: OK : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Fri Aug 14 20:56:40 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012301.html Subject: OK : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Fri Aug 14 20:58:40 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012302.html Subject: OK : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Fri Aug 14 21:00:40 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012303.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] MailHost Improvements
On Thu, 13 Aug 2009 21:22:07 -0700, Alec Mitchell ap...@columbia.edu wrote: 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. There's one additional significant change to Zope behavior here that I forgot to mention. The current implementation sets the python default email transfer and header encoding for 'utf-8' messages to 'quoted-printable', it normally defaults to 'base64'. This is essentially a cosmetic change and makes reading and debugging email messages much more straightforward. It also makes encoded mail less likely to be caught by SPAM filters (some of which dislike base64 mail on principle). At present this change causes one test in CMFDefault to fail, which I'm happy to fix. But it's also not a problem to just remove the line that sets the new 'utf-8' encoding, though I think it dpes have some important advantages. Alec ___ 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] ZTK and Python 2.6, zope.app.zcmlfiles and zope.app.security globalmodules.zcml
I'm trying to get the ZTK KGS tests working with Python 2.6. The tests generate lots of deprecation warnings in part because lots of packages use zope.app.zcmlfiles and zope.app.zcmlfiles includes globalmodules.zcml in zope.app.security and globalmodules.zcml causes lots of standard modules to get imported, including mhlib, which is deprecated in Python 2.6. Whew. :) I know we want to stop using zope.app.zcmlfiles. This make take a while. Too big a job for right now. We should stop using globalmodules.zcml. It's too expensive, too scary, and causing this deprecation warning. If I just delete it's contents, no ztk tests break. :/ I see 3 options, from lowest to highest (but maybe still low) risk: A. Suck it up and live with the deprecation warnings until we get rid of zope.app.zcmlfiles B. Remove the security declaration for mhlib from globalmodules.zcml. Is anyone actually building web applications that publish MH mail folders? C. Stop including globalmodules.zcml from zope.app.zcmlfiles Opinions? FWIW, I vote for B. 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 )
Re: [Zope-dev] [Framework-Team] Re: MailHost Improvements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 15, 2009, at 19:03 , Alec Mitchell wrote: There's one additional significant change to Zope behavior here that I forgot to mention. The current implementation sets the python default email transfer and header encoding for 'utf-8' messages to 'quoted-printable', it normally defaults to 'base64'. This is essentially a cosmetic change and makes reading and debugging email messages much more straightforward. It also makes encoded mail less likely to be caught by SPAM filters (some of which dislike base64 mail on principle). At present this change causes one test in CMFDefault to fail, which I'm happy to fix. But it's also not a problem to just remove the line that sets the new 'utf-8' encoding, though I think it dpes have some important advantages. I'm not an expert, but if quoted-printable is better practice then it should be used and the CMF test should be changed accordingly. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkqHAXIACgkQRAx5nvEhZLKBTQCfcHjWwaRkbRsDo57+bdK2hbsZ CkgAmwcsUFuH0rXBVvimieyeA+XBJ4aG =NHxE -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] ZTK and Python 2.6, zope.app.zcmlfiles and zope.app.security globalmodules.zcml
On Sat, Aug 15, 2009 at 1:41 PM, Jim Fultonj...@zope.com wrote: I'm trying to get the ZTK KGS tests working with Python 2.6. The tests generate lots of deprecation warnings in part because lots of packages use zope.app.zcmlfiles and zope.app.zcmlfiles includes globalmodules.zcml in zope.app.security and globalmodules.zcml causes lots of standard modules to get imported, including mhlib, which is deprecated in Python 2.6. Whew. :) I know we want to stop using zope.app.zcmlfiles. This make take a while. Too big a job for right now. We should stop using globalmodules.zcml. It's too expensive, too scary, and causing this deprecation warning. If I just delete it's contents, no ztk tests break. :/ I see 3 options, from lowest to highest (but maybe still low) risk: A. Suck it up and live with the deprecation warnings until we get rid of zope.app.zcmlfiles B. Remove the security declaration for mhlib from globalmodules.zcml. Is anyone actually building web applications that publish MH mail folders? C. Stop including globalmodules.zcml from zope.app.zcmlfiles Opinions? FWIW, I vote for B. globalmodules also imports deprecated modules sets and multifile. :( I just noticed that globalmodules uses a trick to avoid importing md5 and sha in Python 2.6 by checking whether json is importable. I'll use this same trick for sets, multifile, and mhlib. :) 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 )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
On 14/08/2009 Jim Fulton wrote: On Fri, Aug 14, 2009 at 12:30 PM, Jonas Meurerjo...@freesources.org wrote: ... zope2 releases based on buildout make it very hard for distributors to package zope2. especially as zope2 requires from what i know about buildout (and that's not much), it either requires a working internet connection or a local mirror with exact versions of all required python eggs. i would highly appreciate a final release tarball which includes all required python library/module eggs. This ought to be easy using zc.sourcerelease. We (zc) use it to make self-contained tar balls from which we build rpms. yes, thanks for suggesting that. i don't know much about buildout, and didn't give zc.sourcerelease a try yet, but i'll take a look at it. are the scripts you use to make self-contained tar balls and maybe even the build scripts for rpms available somewhere? i guess they would be of great help for me to understand how zc.sourcerelease works. greetings, jonas ___ 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] Update on ztk kgs: Python 2.6 issues
I've gotten the ztk kgs tests to pass with Python 2.5 on Mac OS X. I've got them mostly passing with on Python 2.6. The only failure I'm getting is for zope.testing and it's due to a Python 2.6 hotshot bug: http://bugs.python.org/issue6710 I'm not sure what to do about this. Perhaps I should disable this test, or maybe even the feature for Python 2.6. When building, I'm getting some deprecation warnings: /Users/jim/.buildout/eggs/infrae.subversion-1.4.5-py2.6.egg/infrae/subversion/Common.py:4: DeprecationWarning: the sets module is deprecated from sets import Set# For python 2.3 compatibility /Users/jim/.buildout/eggs/z3c.recipe.compattest-0.7-py2.6.egg/z3c/recipe/compattest/recipe.py:4: DeprecationWarning: The popen2 module is deprecated. Use the subprocess module. import popen2 It would be great if someone would fix these. :) When running the tests, the only deprecation warnings are from twisted, which we can't do anything about. BTW, if you want to try this yourself, use the buildout at: svn://svn.zope.org/repos/main/zopetoolkit/branches/jim-kgs/kgs 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 )
