Re: [Zope-CMF] Re: Plone needs a release this week
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry for my silence yesterday - there was apparently a cable cut where I live so I've been without phone and internet all day and all night yesterday. Looks like everything is in place now, thanks to Wichert and Yvo. If there are no other urgent issues I'll do GS 1.3.1 and CMF 2.1.0-final tonight. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGuWfyRAx5nvEhZLIRAluuAJ90JbBvyntLjZ6uP9aJcbsQS1i+ggCePIsL LJOF5+oPWfgMpQ6XQxnOqSQ= =jaYa -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] GS bug
Previously Wichert Akkerman wrote: > I want to look at http://dev.plone.org/plone/ticket/6855 before we tag > GS 1.3.1; it might be a GenericSetup bug. This turned out to be a bug in plone.app.form. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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] GS bug
I want to look at http://dev.plone.org/plone/ticket/6855 before we tag GS 1.3.1; it might be a GenericSetup bug. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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] Re: Plone needs a release this week
Hi! Previously yuppie wrote: > Wichert Akkerman wrote: > >But we can't know if component or factory is used. What if someone uses > >a factory which returns a component with a __module__ set? > > Don't know what __module__ usually looks like if the component is > created at registration time. I did hope there would be a way to tell > the difference, but I might be wrong. I don't think there is. > >>But if we have to keep track of registrations anyway, it might be better > >>to do this for all kinds of registrations instead of using a hack. > > > >That is my preference. I have added a statement to REAMDE.txt indicating > >that export of placeless utilies is not supported at the moment. > > Fine. > > But you accidentally checked in your debug code as well. And please > don't forget to forward port your changes to the trunk. Damn, again. Fixed that and merged the changes to trunk. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: Plone needs a release this week
Hi! Wichert Akkerman wrote: Previously yuppie wrote: Wichert Akkerman wrote: Previously yuppie wrote: The check for aq_base should be fine, but your example shows a second issue: type() is used to get the factory. That only works if the class is the factory. So there seems to be indeed a need to store somewhere the factory name :( I think we need that to get the export of placeless components as well. Without it I can't seem to think of a way to determine how the component should be created: using a factory method (which could be the class type itself) or some other way. If 'factory' is used, I also can't see a way to determine the factory used on import. If 'component' is used, there might be a solution: __module__ should be set correctly. Maybe we can loop through the objects in the module and compare them with our component? But we can't know if component or factory is used. What if someone uses a factory which returns a component with a __module__ set? Don't know what __module__ usually looks like if the component is created at registration time. I did hope there would be a way to tell the difference, but I might be wrong. But if we have to keep track of registrations anyway, it might be better to do this for all kinds of registrations instead of using a hack. That is my preference. I have added a statement to REAMDE.txt indicating that export of placeless utilies is not supported at the moment. Fine. But you accidentally checked in your debug code as well. And please don't forget to forward port your changes to the trunk. 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
Re: [Zope-CMF] Re: Plone needs a release this week
Previously yuppie wrote: > Wichert Akkerman wrote: > >Previously yuppie wrote: > >>The check for aq_base should be fine, but your example shows a second > >>issue: type() is used to get the factory. That only works if the class > >>is the factory. > >> > >>So there seems to be indeed a need to store somewhere the factory name :( > > > >I think we need that to get the export of placeless components as well. > >Without it I can't seem to think of a way to determine how the component > >should be created: using a factory method (which could be the class > >type itself) or some other way. > > If 'factory' is used, I also can't see a way to determine the factory > used on import. > > If 'component' is used, there might be a solution: __module__ should be > set correctly. Maybe we can loop through the objects in the module and > compare them with our component? But we can't know if component or factory is used. What if someone uses a factory which returns a component with a __module__ set? > But if we have to keep track of registrations anyway, it might be better > to do this for all kinds of registrations instead of using a hack. That is my preference. I have added a statement to REAMDE.txt indicating that export of placeless utilies is not supported at the moment. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 Tests: 11 OK
Summary of messages to the cmf-tests list. Period Mon Aug 6 12:00:00 2007 UTC to Tue Aug 7 12:00:00 2007 UTC. There were 11 messages: 11 from CMF Unit Tests. Tests passed OK --- Subject: OK : CMF-1.5 Zope-2.7 Python-2.3.6 : Linux From: CMF Unit Tests Date: Mon Aug 6 21:33:32 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-August/005888.html Subject: OK : CMF-1.5 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Mon Aug 6 21:35:03 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-August/005889.html Subject: OK : CMF-1.5 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Aug 6 21:36:34 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-August/005890.html Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Mon Aug 6 21:38:06 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-August/005891.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Aug 6 21:39:36 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-August/005892.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Aug 6 21:41:07 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-August/005893.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Aug 6 21:42:38 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-August/005894.html Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Aug 6 21:44:09 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-August/005895.html Subject: OK : CMF-2.1 Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Aug 6 21:45:40 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-August/005896.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Aug 6 21:47:12 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-August/005897.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Aug 6 21:48:43 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-August/005898.html ___ 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: Plone needs a release this week
Wichert Akkerman wrote: Previously yuppie wrote: The check for aq_base should be fine, but your example shows a second issue: type() is used to get the factory. That only works if the class is the factory. So there seems to be indeed a need to store somewhere the factory name :( I think we need that to get the export of placeless components as well. Without it I can't seem to think of a way to determine how the component should be created: using a factory method (which could be the class type itself) or some other way. If 'factory' is used, I also can't see a way to determine the factory used on import. If 'component' is used, there might be a solution: __module__ should be set correctly. Maybe we can loop through the objects in the module and compare them with our component? But if we have to keep track of registrations anyway, it might be better to do this for all kinds of registrations instead of using a hack. 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
Re: [Zope-CMF] Re: Plone needs a release this week
Previously yuppie wrote: > The check for aq_base should be fine, but your example shows a second > issue: type() is used to get the factory. That only works if the class > is the factory. > > So there seems to be indeed a need to store somewhere the factory name :( I think we need that to get the export of placeless components as well. Without it I can't seem to think of a way to determine how the component should be created: using a factory method (which could be the class type itself) or some other way. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: Plone needs a release this week
Wichert Akkerman wrote: Previously yuppie wrote: Wichert Akkerman wrote: I get something else: if I import this: the export looks like this: That seems to be a similar but different bug. this is caused by the zope.component.registerUtility not storing the factory method but the return value from the factory, so we no longer have the factory method available when we export. The only way to fix that appears to be for us to keep a a registry of factory methods in the setup tool. That may be too big of a change in a minor release though. Not sure if your issue is a problem in real life. AFAICS this only happens if you use a factory that is meant for ZODB objects. In that case you should register an object. Ah, that makes sense I guess. My test-case was this: from Products.MailHost.MailHost import MailHost def genMail(): return MailHost() and a MailHost is indeed a ZODB object. The check for aq_base should be fine, but your example shows a second issue: type() is used to get the factory. That only works if the class is the factory. So there seems to be indeed a need to store somewhere the factory name :( 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
Re: [Zope-CMF] Re: Plone needs a release this week
Previously yuppie wrote: > Hi! > > > Wichert Akkerman wrote: > >Previously yuppie wrote: > >>Wichert Akkerman wrote: > >>>Previously yuppie wrote: > - The exports created by the new components handler are still flawed, > ISiteRoot and placeless components are not exported correctly. > >>>I'm quite sure I fixed that: I was able to export the components and > >>>import them again. Has that been broken since? > >>Don't know since when these things are broken, but in the latest code > >>there are these 2 bugs: > >> > >> > >>1.) Exporting the ISiteRoot utility, 'object' should be empty. But I get > >>this instead: > >> > >> >> object="SITE_ID"/> > >> > >> > >>2.) By placeless components I mean something like this: > >> > >> > >> > >>The import works fine, but the export looks like this: > >> > >> > > Attached is a diff for test_components.py. Unfortunately the > AssertionErrors are a bit cryptic, but they show that the factory is > exported instead of the component. I'll take a look at those. > >I get something else: if I import this: > > > > > > > >the export looks like this: > > > > > > That seems to be a similar but different bug. > > >this is caused by the zope.component.registerUtility not storing the > >factory method but the return value from the factory, so we no longer > >have the factory method available when we export. > > > >The only way to fix that appears to be for us to keep a a registry of > >factory methods in the setup tool. That may be too big of a change > >in a minor release though. > > Not sure if your issue is a problem in real life. AFAICS this only > happens if you use a factory that is meant for ZODB objects. In that > case you should register an object. Ah, that makes sense I guess. My test-case was this: from Products.MailHost.MailHost import MailHost def genMail(): return MailHost() and a MailHost is indeed a ZODB object. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: Plone needs a release this week
Hi! Wichert Akkerman wrote: Previously yuppie wrote: Wichert Akkerman wrote: Previously yuppie wrote: - The exports created by the new components handler are still flawed, ISiteRoot and placeless components are not exported correctly. I'm quite sure I fixed that: I was able to export the components and import them again. Has that been broken since? Don't know since when these things are broken, but in the latest code there are these 2 bugs: 1.) Exporting the ISiteRoot utility, 'object' should be empty. But I get this instead: 2.) By placeless components I mean something like this: The import works fine, but the export looks like this: Attached is a diff for test_components.py. Unfortunately the AssertionErrors are a bit cryptic, but they show that the factory is exported instead of the component. I get something else: if I import this: the export looks like this: That seems to be a similar but different bug. this is caused by the zope.component.registerUtility not storing the factory method but the return value from the factory, so we no longer have the factory method available when we export. The only way to fix that appears to be for us to keep a a registry of factory methods in the setup tool. That may be too big of a change in a minor release though. Not sure if your issue is a problem in real life. AFAICS this only happens if you use a factory that is meant for ZODB objects. In that case you should register an object. So my vote would be: document that exporting of utility factories is currently not supported and will be fixed in GenericSetup 1.4 and tag the current code as 1.3.1. I'm fine with that. Cheers, Yuppie Index: Products/GenericSetup/tests/test_components.py === --- Products/GenericSetup/tests/test_components.py (revision 78655) +++ Products/GenericSetup/tests/test_components.py (working copy) @@ -69,6 +69,8 @@ def verify(self): return True +dummy_utility = DummyUtility() + class DummyTool(SimpleItem): """A dummy tool.""" @@ -113,6 +115,9 @@ + @@ -135,6 +140,9 @@ tool2 = aq_base(self.app['dummy_tool2']) obj.registerUtility(tool2, IDummyInterface, name=u'dummy tool name2') +obj.registerUtility(dummy_utility, IDummyInterface, +name=u'dummy utility name') + def test_body_get(self): self._populate(self._obj) context = DummyExportContext(self.app) @@ -171,6 +179,10 @@ self.failUnless(IDummyInterface.providedBy(util)) self.failUnless(util.verify()) +util = queryUtility(IDummyInterface, name=u'dummy utility name') +self.failUnless(IDummyInterface.providedBy(util)) +self.failUnless(util.verify()) + util = queryUtility(IDummyInterface) self.failUnless(IDummyInterface.providedBy(util)) self.failUnless(util.verify()) ___ 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] Re: Plone needs a release this week
Previously Jens Vagelpohl wrote: > I'm supposed to do a CMF 2.1.0 release today, but the state of these > issues is unclear. Wichert, did you look at it? There are no checkins > into either CMF or GS as far as I can see. Export now yields this: I took care of the GenericSetup changes as far as I think are possible. Exporting of utility factories is broken but requires more changes than I'm willing to make in a minor release. I've also gone over the docstrings in CMFCore to check the BBB remarks there and cleaned up those that were no longer correct. I don't think there are any showstoppers left. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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] Re: Plone needs a release this week
Previously yuppie wrote: > - It might be useful to review the docstrings in CMFCore.utils and > interfaces._tools. There are misleading comments like "BBB: for use in > 'getToolByName'; in the future, prefer > 'zapi.getUtility(IActionsTool)'." Seems not all docs reflect the latest > tools-as-utilities changes. I took care of that one. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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] Re: Plone needs a release this week
Previously yuppie wrote: > Wichert Akkerman wrote: > >Previously yuppie wrote: > >>- The exports created by the new components handler are still flawed, > >>ISiteRoot and placeless components are not exported correctly. > > > >I'm quite sure I fixed that: I was able to export the components and > >import them again. Has that been broken since? > > Don't know since when these things are broken, but in the latest code > there are these 2 bugs: > > > 1.) Exporting the ISiteRoot utility, 'object' should be empty. But I get > this instead: > > object="SITE_ID"/> > > > 2.) By placeless components I mean something like this: > > > > The import works fine, but the export looks like this: > > I get something else: if I import this: the export looks like this: this is caused by the zope.component.registerUtility not storing the factory method but the return value from the factory, so we no longer have the factory method available when we export. The only way to fix that appears to be for us to keep a a registry of factory methods in the setup tool. That may be too big of a change in a minor release though. So my vote would be: document that exporting of utility factories is currently not supported and will be fixed in GenericSetup 1.4 and tag the current code as 1.3.1. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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] Re: Plone needs a release this week
Previously yuppie wrote: > Wichert Akkerman wrote: > >Previously yuppie wrote: > >>- The exports created by the new components handler are still flawed, > >>ISiteRoot and placeless components are not exported correctly. > > > >I'm quite sure I fixed that: I was able to export the components and > >import them again. Has that been broken since? > > Don't know since when these things are broken, but in the latest code > there are these 2 bugs: > > > 1.) Exporting the ISiteRoot utility, 'object' should be empty. But I get > this instead: > > object="SITE_ID"/> I fixed this one again. > 2.) By placeless components I mean something like this: > > > > The import works fine, but the export looks like this: > > Do you have a failing test or another way to reproduce this? Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 tseaver - "CMF needs View-based TypeInformation", [Accepted] http://www.zope.org/Collectors/CMF/437 yuppie - "purge_old in runAllImportSteps not working", [Accepted] http://www.zope.org/Collectors/CMF/455 Pending / Deferred Issues - "workflow notify success should be after reindex", [Deferred] http://www.zope.org/Collectors/CMF/389 Pending / Deferred Features - "CMFTopic Does Not Cache", [Deferred] http://www.zope.org/Collectors/CMF/295 - "iCal support for CMFCalendar", [Pending] http://www.zope.org/Collectors/CMF/487 ___ 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
