[Zope-CMF] Re: [RFC] [Patch] GenericSetup and encodings
yuppie wrote: Hi! Yves Bastide wrote: yuppie wrote: 3.) GenericSetup is not tested with non-ASCII UTF-8 site settings. AFAIK import works, but not export. I consider this a bug. [...] UnicodeDecodeError: 'ascii' codec can't decode byte 0xf4 in position 20: ordinal not in range(128) This traceback just confirms that export does not work. Is import also broken? Differently: it may or may not raise ... And Zope treats properties as iso8859-15 anyway. Fresh install of Zope trunk (after a long struggle; make instance now works but make install is broken?) and CMF trunk, with ~/src/CMF$ svn diff Index: CMFDefault/profiles/default/properties.xml === --- CMFDefault/profiles/default/properties.xml (revision 68514) +++ CMFDefault/profiles/default/properties.xml (working copy) @@ -1,6 +1,6 @@ - Portal + Portàl [EMAIL PROTECTED] Fails when CMFDefault.factory.addConfiguredSite calls createSnapshot. Here's a minimal patch for GenericSetup not to raise on the previous case (Demonstration product. Not for sale.) [EMAIL PROTECTED]:~/src/CMF$ svn diff GenericSetup/ Index: GenericSetup/context.py === --- GenericSetup/context.py (revision 68514) +++ GenericSetup/context.py (working copy) @@ -475,7 +475,7 @@ if isinstance( body, unicode ): encoding = self.getEncoding() if encoding is None: -body = body.encode() +body = body.encode('UTF-8') else: body = body.encode( encoding ) Index: GenericSetup/utils.py === --- GenericSetup/utils.py (revision 68514) +++ GenericSetup/utils.py (working copy) @@ -625,6 +625,8 @@ else: if prop_map.get('type') == 'boolean': prop = str(bool(prop)) +elif isinstance(prop, str): +prop = prop.decode('UTF-8') elif not isinstance(prop, basestring): prop = str(prop) child = self._doc.createTextNode(prop) [EMAIL PROTECTED]:~/src/CMF$ With this applied, Portàl (u'Port\xe0l'), which becomes 'Port\xc3\xa0l', is displayed as Portà l ... Zope does input--output properties in utf-8, but stores them in iso8859. Sigh. Thanks for setting me right. What's the usefulness of getEncoding()? As you say, exported files don't need to be other than utf-8 encoded. I guess it just exists for historical reasons. Might it be removed, or default'ed to utf-8? Do people already rely on it? Well, I think I can wriggle out of most of my problems using translation. And I'll try and write UTF-8 unit tests if nobody beats me to it. That would be great. Hmm, by adding to an existing test suite, or creating a new one? Cheers, Yuppie Thanks, yves ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: zLOG -> logging
Florent Guillaume wrote: Yves Bastide wrote: And CPS 3.3 and 3.4 have been using Zope 2.9 since its inception, and is the only recommended "stable" platform for them. Though they also flood the console with zLOG deprecation warnings ;-) (I incrementally patched the worst offenders on my local copy, but never sent the result mainly because of the BLATHER/TRACE/DEBUG-to-debug impedance mismatch) Well you're better off patching zLOG then, to make it not send the warning :) Too easy :-) (And I just saw ZODB.loglevels.{TRACE,BLATHER}. /me go hiding) Florent yves ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: zLOG -> logging
Yves Bastide wrote: And CPS 3.3 and 3.4 have been using Zope 2.9 since its inception, and is the only recommended "stable" platform for them. Though they also flood the console with zLOG deprecation warnings ;-) (I incrementally patched the worst offenders on my local copy, but never sent the result mainly because of the BLATHER/TRACE/DEBUG-to-debug impedance mismatch) Well you're better off patching zLOG then, to make it not send the warning :) Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: zLOG -> logging
Florent Guillaume wrote: And CPS 3.3 and 3.4 have been using Zope 2.9 since its inception, and is the only recommended "stable" platform for them. Though they also flood the console with zLOG deprecation warnings ;-) (I incrementally patched the worst offenders on my local copy, but never sent the result mainly because of the BLATHER/TRACE/DEBUG-to-debug impedance mismatch) Florent yves ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: zLOG -> logging
Jens Vagelpohl wrote: On 7 Jun 2006, at 20:24, Andreas Jung wrote: I have the impression that Zope 2.9 is ignored by most ppl :-) Absolutely not, I test CMF 2.0 against Zope 2.9 ;) And CPS 3.3 and 3.4 have been using Zope 2.9 since its inception, and is the only recommended "stable" platform for them. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] zLOG -> logging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7 Jun 2006, at 20:24, Andreas Jung wrote: --On 7. Juni 2006 20:16:49 +0200 Jens Vagelpohl <[EMAIL PROTECTED]> wrote: On 7 Jun 2006, at 18:26, Florent Guillaume wrote: Is it ok if I change CMF 1.6 (currently in beta) to use the logging module instead of zLOG? zLOG spouts lots of warnings under Zope 2.10 and this sucks. Yeah, should be fine. You're using CMF 1.6 under Zope 2.10? I only ever test it under Zope 2.8. I have the impression that Zope 2.9 is ignored by most ppl :-) Absolutely not, I test CMF 2.0 against Zope 2.9 ;) jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEhyH+RAx5nvEhZLIRAvyIAJ0Vo5IHiWggXZwGTbpeFiLbR0wdEACcC9VD QlKHy8sVqzeG+kCiLMi+9Y0= =mK2v -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] zLOG -> logging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7 Jun 2006, at 18:26, Florent Guillaume wrote: Is it ok if I change CMF 1.6 (currently in beta) to use the logging module instead of zLOG? zLOG spouts lots of warnings under Zope 2.10 and this sucks. Yeah, should be fine. You're using CMF 1.6 under Zope 2.10? I only ever test it under Zope 2.8. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEhxgRRAx5nvEhZLIRAkOwAKC1c5lv0wgGt8yhaLDHVwR9j0FGqwCeMWHh Z5xRUu7WYaVNEf/7Nca6rz8= =hq6J -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: zLOG -> logging
On Wed, 2006-07-06 at 18:26 +0200, Florent Guillaume wrote: > Is it ok if I change CMF 1.6 (currently in beta) to use the logging > module instead of zLOG? > zLOG spouts lots of warnings under Zope 2.10 and this sucks. +1 -- 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-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [RFC] [Patch] GenericSetup and encodings
Hi! Yves Bastide wrote: yuppie wrote: 2.) GenericSetup explicitly doesn't support non-UTF-8 site settings. If someone provides a good patch this feature can be added. But with the problems you mention later ('default_charset', 'management_page_charset', and so on), how would you envision it? Maybe PropertyManagerHelpers should have a _properties_encoding attribute that defaults to utf-8 and can be easily overridden by subclasses. Or we try to set the default encoding the same way manage_propertiesForm does. That might be even better than using always utf-8. The adapters shipped with CMF would be responsible for CMF-specific modifications to _properties_encoding. 3.) GenericSetup is not tested with non-ASCII UTF-8 site settings. AFAIK import works, but not export. I consider this a bug. Neither: CMF trunk, change portal_types/Document's title to 'Dôcument', export: 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 Products.GenericSetup.tool, line 471, in manage_exportAllSteps Module Products.GenericSetup.tool, line 272, in runAllExportSteps Module Products.GenericSetup.tool, line 736, in _doRunExportSteps Module Products.CMFCore.exportimport.typeinfo, line 198, in exportTypesTool Module Products.GenericSetup.utils, line 728, in exportObjects Module Products.GenericSetup.utils, line 722, in exportObjects Module Products.GenericSetup.utils, line 501, in _exportBody Module xml.dom.minidom, line 62, in toprettyxml Module StringIO, line 271, in getvalue UnicodeDecodeError: 'ascii' codec can't decode byte 0xf4 in position 20: ordinal not in range(128) This traceback just confirms that export does not work. Is import also broken? Thanks for setting me right. What's the usefulness of getEncoding()? As you say, exported files don't need to be other than utf-8 encoded. I guess it just exists for historical reasons. Well, I think I can wriggle out of most of my problems using translation. And I'll try and write UTF-8 unit tests if nobody beats me to it. That would be great. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: zLOG -> logging
Florent Guillaume wrote: Is it ok if I change CMF 1.6 (currently in beta) to use the logging module instead of zLOG? zLOG spouts lots of warnings under Zope 2.10 and this sucks. +1 if you forward port the fixes ;) (see http://www.zope.org/Collectors/CMF/439) Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] zLOG -> logging
Is it ok if I change CMF 1.6 (currently in beta) to use the logging module instead of zLOG? zLOG spouts lots of warnings under Zope 2.10 and this sucks. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [RFC] [Patch] GenericSetup and encodings
yuppie wrote: Hi Yves! Yves Bastide wrote: GenericSetup has problems handling non-ASCII data. 1.) GenericSetup explicitly doesn't support non-UTF-8 XML in profiles. UTF-8 is the default encoding for XML and I can't see a need to support other XML encodings. As output, right? Agreed. 2.) GenericSetup explicitly doesn't support non-UTF-8 site settings. If someone provides a good patch this feature can be added. But with the problems you mention later ('default_charset', 'management_page_charset', and so on), how would you envision it? 3.) GenericSetup is not tested with non-ASCII UTF-8 site settings. AFAIK import works, but not export. I consider this a bug. Neither: CMF trunk, change portal_types/Document's title to 'Dôcument', export: 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 Products.GenericSetup.tool, line 471, in manage_exportAllSteps Module Products.GenericSetup.tool, line 272, in runAllExportSteps Module Products.GenericSetup.tool, line 736, in _doRunExportSteps Module Products.CMFCore.exportimport.typeinfo, line 198, in exportTypesTool Module Products.GenericSetup.utils, line 728, in exportObjects Module Products.GenericSetup.utils, line 722, in exportObjects Module Products.GenericSetup.utils, line 501, in _exportBody Module xml.dom.minidom, line 62, in toprettyxml Module StringIO, line 271, in getvalue UnicodeDecodeError: 'ascii' codec can't decode byte 0xf4 in position 20: ordinal not in range(128) It treats strings sometimes as ASCII, sometimes as UTF-8, yet it has access to two variables: its own ISetupContext.getEncoding() (whose use I didn't fully grok) and CMF's ISetupContext.getSite().getProperty('default_charset'). Sorry, but your assumptions are wrong: - The default setup tool creates export contexts without specifying the encoding, so ISetupContext.getEncoding() returns always None. And even if it would be set it represents the encoding of the exported files, not the site encoding. - getSite().getProperty('default_charset') is CMF specific and should not be used in GenericSetup. - The adapters adapt ISetupEnviron, not ISetupContext. getEncoding() and getSite() are not always available. Thanks for setting me right. What's the usefulness of getEncoding()? As you say, exported files don't need to be other than utf-8 encoded. First of all we need unit tests that make sure UTF-8 works and I think this should be the default used by GenericSetup. Code that needs to know how to find the site encoding can't be generic. Yep. There is an additional problem: If tools use the default property edit page from OFS the properties might have a different encoding than 'default_charset' of the site. Since the default 'management_page_charset' is UTF-8 we have less trouble if we allow only UTF-8. D'oh! /manage is 8859-15, /manage_menu is -1 and manage_propertiesForm UTF-8. No wonder Firefox sometimes gets confused :-) Well, I think I can wriggle out of most of my problems using translation. And I'll try and write UTF-8 unit tests if nobody beats me to it. Thanks! Cheers, Yuppie yves ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [RFC] [Patch] GenericSetup and encodings
Hi Florent! Florent Guillaume wrote: Let's not forget also that the goal in CMF 2 (I think) is to have all content be unicode strings, never encoded ones. In that case GenericSetup only has to deal with the XML file's encoding (always UTF-8 anyway) but that's all. That's a long term goal. AFAICT nobody is working on it. CPS 3 was a pure-latin1 application for various historical reasons, so we modified a number of I/O adapters so that they encode/decode properly what GenericSetup works with. CPS 3.4 tends to remove the hardcoding of latin-1 to the site's default_charset property, but that's not been taken into account everywhere, although it should. CPS 4 will be purely unicode, and won't need all that shit. Also configuration data? I guess CPS 4 will still use some CMF tools and a lot of work will be necessary to make them play nice with unicode. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [RFC] [Patch] GenericSetup and encodings
yuppie wrote: Hi Yves! Yves Bastide wrote: GenericSetup has problems handling non-ASCII data. 1.) GenericSetup explicitly doesn't support non-UTF-8 XML in profiles. UTF-8 is the default encoding for XML and I can't see a need to support other XML encodings. 2.) GenericSetup explicitly doesn't support non-UTF-8 site settings. If someone provides a good patch this feature can be added. 3.) GenericSetup is not tested with non-ASCII UTF-8 site settings. AFAIK import works, but not export. I consider this a bug. It treats strings sometimes as ASCII, sometimes as UTF-8, yet it has access to two variables: its own ISetupContext.getEncoding() (whose use I didn't fully grok) and CMF's ISetupContext.getSite().getProperty('default_charset'). Sorry, but your assumptions are wrong: - The default setup tool creates export contexts without specifying the encoding, so ISetupContext.getEncoding() returns always None. And even if it would be set it represents the encoding of the exported files, not the site encoding. - getSite().getProperty('default_charset') is CMF specific and should not be used in GenericSetup. - The adapters adapt ISetupEnviron, not ISetupContext. getEncoding() and getSite() are not always available. Attached is a patch using both of them and somewhat working in my setup. Can knowledgeable people comment on it before I enter a collector issue? (I'm using GS alongside with CPS, which also needs some patching; yet basic things, such as exporting-importing an iso8859-15 Title in a CMF charset-default'ed to iso8859-15, should work) First of all we need unit tests that make sure UTF-8 works and I think this should be the default used by GenericSetup. Code that needs to know how to find the site encoding can't be generic. There is an additional problem: If tools use the default property edit page from OFS the properties might have a different encoding than 'default_charset' of the site. Since the default 'management_page_charset' is UTF-8 we have less trouble if we allow only UTF-8. Let's not forget also that the goal in CMF 2 (I think) is to have all content be unicode strings, never encoded ones. In that case GenericSetup only has to deal with the XML file's encoding (always UTF-8 anyway) but that's all. CPS 3 was a pure-latin1 application for various historical reasons, so we modified a number of I/O adapters so that they encode/decode properly what GenericSetup works with. CPS 3.4 tends to remove the hardcoding of latin-1 to the site's default_charset property, but that's not been taken into account everywhere, although it should. CPS 4 will be purely unicode, and won't need all that shit. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [RFC] [Patch] GenericSetup and encodings
Hi Yves! Yves Bastide wrote: GenericSetup has problems handling non-ASCII data. 1.) GenericSetup explicitly doesn't support non-UTF-8 XML in profiles. UTF-8 is the default encoding for XML and I can't see a need to support other XML encodings. 2.) GenericSetup explicitly doesn't support non-UTF-8 site settings. If someone provides a good patch this feature can be added. 3.) GenericSetup is not tested with non-ASCII UTF-8 site settings. AFAIK import works, but not export. I consider this a bug. It treats strings sometimes as ASCII, sometimes as UTF-8, yet it has access to two variables: its own ISetupContext.getEncoding() (whose use I didn't fully grok) and CMF's ISetupContext.getSite().getProperty('default_charset'). Sorry, but your assumptions are wrong: - The default setup tool creates export contexts without specifying the encoding, so ISetupContext.getEncoding() returns always None. And even if it would be set it represents the encoding of the exported files, not the site encoding. - getSite().getProperty('default_charset') is CMF specific and should not be used in GenericSetup. - The adapters adapt ISetupEnviron, not ISetupContext. getEncoding() and getSite() are not always available. Attached is a patch using both of them and somewhat working in my setup. Can knowledgeable people comment on it before I enter a collector issue? (I'm using GS alongside with CPS, which also needs some patching; yet basic things, such as exporting-importing an iso8859-15 Title in a CMF charset-default'ed to iso8859-15, should work) First of all we need unit tests that make sure UTF-8 works and I think this should be the default used by GenericSetup. Code that needs to know how to find the site encoding can't be generic. There is an additional problem: If tools use the default property edit page from OFS the properties might have a different encoding than 'default_charset' of the site. Since the default 'management_page_charset' is UTF-8 we have less trouble if we allow only UTF-8. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: GenericSetup now incompatible with Zope 2.8?
Hi Philipp! Philipp von Weitershausen wrote: yuppie wrote: Should be fixed now: http://svn.zope.org/?rev=68474&view=rev Simply avoiding the cleanup in Zope 2.8 isn't a proper fix. You should instead do the following (which works across all Zopes): from zope.testing.cleanup import CleanUp CleanUp().cleanUp() Thanks for keeping an eye on these checkins, but I believe in this case it is a proper fix. You just can't see it in the diff. There is nothing to clean up in Zope 2.8. These tests require the traversing setup only in Zope 2.10 and a separate 'traversing.zcml' does not exist in earlier Zope/Five versions. I attached the complete code. Cheers, Yuppie class SecurityRequestTest(ZopeTestCase): def setUp(self): import Products from AccessControl.SecurityManagement import newSecurityManager ZopeTestCase.setUp(self) try: # BBB: for Zope 2.9 from Products.Five.traversable import FiveTraversable except ImportError: zcml.load_config('meta.zcml', Products.Five) zcml.load_config('traversing.zcml', Products.Five) self.root = self.app newSecurityManager(None, OmnipotentUser().__of__(self.app.acl_users)) def tearDown(self): from AccessControl.SecurityManagement import noSecurityManager noSecurityManager() ZopeTestCase.tearDown(self) try: from zope.testing.cleanup import cleanUp cleanUp() except ImportError: # BBB: for Zope 2.8 pass ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] CMF Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open jens - "CachingPolicyManager: Support OFS.Cache.CacheManager", [Accepted] http://www.zope.org/Collectors/CMF/408 mhammond - "Windows DevelopmentMode penalty in CMFCore.DirectoryView", [Accepted] http://www.zope.org/Collectors/CMF/366 Pending / Deferred Issues - "Wrong cache association for FSObject", [Pending] http://www.zope.org/Collectors/CMF/255 - "CMFSetup: Windows exports contain CR/LF, LF and even CR newlines", [Pending] http://www.zope.org/Collectors/CMF/266 - "FSPropertiesObject.py cannot handle multiline input for lines, text attributes", [Deferred] http://www.zope.org/Collectors/CMF/271 - "Can't invalidate skin items in a RAMCacheManager", [Pending] http://www.zope.org/Collectors/CMF/343 - "CMFSetup: Workflow Tool export fails with workflows which have scripts", [Pending] http://www.zope.org/Collectors/CMF/373 - "CMFCore.Skinnable.SkinnableObjectManager can merge skin data", [Pending] http://www.zope.org/Collectors/CMF/375 - "Proxy Roles does't work for a Script using portal_catalog.searchResults", [Pending] http://www.zope.org/Collectors/CMF/380 - "workflow notify success should be after reindex", [Pending] http://www.zope.org/Collectors/CMF/389 - "'except ...: pass' in CMFCore/TypesTool.py:_queryFactoryMethod() nullifies VerboseSecurity", [Pending] http://www.zope.org/Collectors/CMF/410 - "Logging broken", [Pending] http://www.zope.org/Collectors/CMF/439 Pending / Deferred Features - "Favorite.py: queries and anchors in remote_url", [Pending] http://www.zope.org/Collectors/CMF/26 - "DefaultDublinCore should have Creator property", [Pending] http://www.zope.org/Collectors/CMF/61 - "path criteria on Topic should honor VHM", [Pending] http://www.zope.org/Collectors/CMF/111 - "Document.py: universal newlines", [Pending] http://www.zope.org/Collectors/CMF/174 - "Add condition for transition's action like other action", [Pending] http://www.zope.org/Collectors/CMF/207 - "Major action enhancement", [Pending] http://www.zope.org/Collectors/CMF/232 - "portal_type is undefined in initialization code", [Pending] http://www.zope.org/Collectors/CMF/248 - "CMFTopic Does Not Cache", [Deferred] http://www.zope.org/Collectors/CMF/295 - "Wishlist: a flag that tags the selected action.", [Pending] http://www.zope.org/Collectors/CMF/301 - "CMFDefault should make use of allowCreate()", [Pending] http://www.zope.org/Collectors/CMF/340 - "Nested Skins", [Deferred] http://www.zope.org/Collectors/CMF/377 - "CatalogVariableProvider code + tests", [Pending] http://www.zope.org/Collectors/CMF/378 - "manage_doCustomize() : minor additions", [Pending] http://www.zope.org/Collectors/CMF/382 - "CMF needs View-based TypeInformation", [Pending] http://www.zope.org/Collectors/CMF/437 - "Marker attributes should be deprecated", [Pending] http://www.zope.org/Collectors/CMF/440 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: GenericSetup now incompatible with Zope 2.8?
yuppie wrote: > Jens Vagelpohl wrote: >> This checkin seems to have broken Zope 2.8-compatibility: >> >> http://svn.zope.org/GenericSetup/trunk/tests/common.py?rev=68391&r1=41338&r2=68391 >> >> >> Specifically, the line "from zope.testing.cleanup import cleanUp" >> breaks Zope 2.8, I checked all stable tags (2.8.5, 2.8.6, 2.8.7) and >> there is no toplevel name "cleanUp" in zope.testing.cleanup. >> >> DEPENDENCIES.txt still claims it works with Zope 2.8.5 and higher. One >> or the other needs changing, either DEPENDENCIES.txt needs updating >> or, if this breakage was inadvertently introduced, common.py needs >> fixing. > > Sorry, my mistake. I only tested against Zope 2.9 and 2.10 before > checking in. > > Should be fixed now: http://svn.zope.org/?rev=68474&view=rev Simply avoiding the cleanup in Zope 2.8 isn't a proper fix. You should instead do the following (which works across all Zopes): from zope.testing.cleanup import CleanUp CleanUp().cleanUp() ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests