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] 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: utility interface=Products.CMFCore.interfaces._content.ISiteRoot object=SITE_ID/ I fixed this one again. 2.) By placeless components I mean something like this: utility component=foo.bar interface=foo.IBar/ The import works fine, but the export looks like this: utility factory=foo.Bar interface=foo.IBar/ 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
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: utility interface=Products.CMFCore.interfaces._content.ISiteRoot object=SITE_ID/ 2.) By placeless components I mean something like this: utility component=foo.bar interface=foo.IBar/ The import works fine, but the export looks like this: utility factory=foo.Bar interface=foo.IBar/ I get something else: if I import this: utility interface=foo.IBar factory=foo.bar/ the export looks like this: utility interface=foo.IBar object=/ 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 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: 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: utility interface=Products.CMFCore.interfaces._content.ISiteRoot object=SITE_ID/ 2.) By placeless components I mean something like this: utility component=foo.bar interface=foo.IBar/ The import works fine, but the export looks like this: utility factory=foo.Bar interface=foo.IBar/ 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: utility interface=foo.IBar factory=foo.bar/ the export looks like this: utility interface=foo.IBar object=/ 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() utility interface=Products.MailHost.interfaces.IMailHost factory=Products.GenericSetup.hack.genMail/ 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
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
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
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
Re: [Zope-CMF] Re: Plone needs a release this week
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5 Aug 2007, at 20:15, yuppie 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: placeless component: utility interface=Products.CMFCore.interfaces._tools.IMetadataTool object=portal_metadata/ This is not what I would call placeless. My example looks like this: utility component=foo.bar interface=foo.IBar/ 'foo.bar' is the dotted name of an object in a python module, not in the ZODB. The 'component' feature is not used by the CMF, but GenericSetup claims to support it. If you're speaking about something that's not even used by the CMF then that won't be a shostopper for the CMF. For GS, IMHO, this is a bit of an esoteric feature. I don't know any place that uses it. If there's a decision to be made between get the goddamn release out and wait until someone figures out this piece in GS I'll choose the first option. the site root: utility interface=Products.CMFCore.interfaces._content.ISiteRoot object=SITE_ID/ I was able to import a snapshot that contained a componentregistry export of this format, though. I guess this only works with a site that has the same ID and no sub- object with this ID. Not very reliable and confusing. Well, I imported it into a site with a different ID. The Components tab you provided shows the old ID, unfortunately. However, I don't know if that makes a difference in real life or if it's just a cosmetic issue. Can I go ahead and roll a GS 1.3.1 and then a CMF 2.1.0 using GS 1.3.1 or are there any showstoppers left? I made a list of things that should be fixed in my opinion. But I can't decide what is a showstopper and what isn't. If it's not an obvious showstopper I feel it's not worth holding up Wichert. Would you agree? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGtjKcRAx5nvEhZLIRAgZNAKCEta0hWr4cO0CIfLvSIbqI1s0TcACfWyv0 iLkfue7OIC5i1E0LzzLYY5g= =nzNS -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] Re: Plone needs a release this week
Am 31.07.2007 um 17:17 schrieb Tres Seaver: 'imperative' indicates that the profile executes arbitrary Python code; 'declarative' indecates that the profile applies external configuration data, read from one or more data files in the profile. Running two imperative profiles, A and B, may create different effects based on the order in which they are run, or whether they are run more than once. With declarative profiles, OTOH, the state is all captured in the data file(s), which means there are no ordering depencencies, and it is always safe (idempotent) to reapply the step. Thanks for the explanation, Tres. I still find the term distinction somewhat confusing and would suggest runtime or ad hoc for the second one but if it is an established term in software development then who am I to rewrite the book! While I have a fairly intense dislike of XML I am fully in favour on configuration being kept external to an application although I don't see how conflicts: two products wishing to configure the same object differently can be resolved this way. However, it seems I am not the only one who been confused by the discussion. Would it make sense to move it to a wiki where we have use cases, problems, etc? What I am personally missing are examples of current gotchas and how they can be resolved. Does http://zope.org/Products/CMF/docs/requirements/proposals/ GenericSetup_architectureflect the current status? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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: utility interface=Products.CMFCore.interfaces._content.ISiteRoot object=SITE_ID/ 2.) By placeless components I mean something like this: utility component=foo.bar interface=foo.IBar/ The import works fine, but the export looks like this: utility factory=foo.Bar interface=foo.IBar/ I'm quite sure I had both of those working last time I touched GS. I'll poke at them later this week. 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
Am 31.07.2007 um 15:51 schrieb yuppie: AFAICS the premature GenericSetup 1.3 release has the biggest issues: I'm behind the loop on GenericSetup having only encountered it when writing a content type for a single site. I would appreciate an explanation of the difference between declarative and imperative as linguistically they are almost identical. I have never done imports exports so would appreciate knowing where to go to read up on them so that I can contribute to the debate or at least understand it fully. ... I still consider the VERSION.txt support a mis-feature. VERSION.txt is really nasty anyway but if it is still around you are right: the profile version is not necessarily the same as the product version and so nothing should assume this. five.localsitemanager still has no UI for inspecting and editing component registrations. I added the 'components_xmlconfig.html' view to GenericSetup as an alternative way to do this, but a normal UI would still be useful. CMF seems to be in good shape, but the migration code and documentation could need some cleanup: - The 2.1 migration should use the new 'upgradeStep' feature, the on-the-fly migration code in PortalObjectBase.getSiteManager should be replaced by an 'upgradeStep' - 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. Yes, please! I recently really struggled writing a browser view because of the lack of doc strings. I can only assume that BBB has something to do with something bad. I think the most important issues can be resolved before the weekend *if* some people are willing to help. Having recently given a presentation (in German) on CMF 2.1 I hope at least to be contributing to the documentation. However, as noted above there are significant areas with which I have little or no experience. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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! Jens Vagelpohl wrote: On 20 Jul 2007, at 11:00, Wichert Akkerman wrote: Previously Jens Vagelpohl wrote: Next step: What needs fixing for the final? There has been a surprising lack of response to this question. Since I need a CMF 2.1-final for Plone in a few weeks that could be very positive news for me but I have a suspicion that some of you have some outstanding issues. Or is there really nothing that needs to be done before going final? If no one objects I will cut a CMF 2.1.0-final the weekend of August 5. I finally found some time to have a closer look at the latest code. AFAICS the premature GenericSetup 1.3 release has the biggest issues: - 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? 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alright, I'm going to do the following today/tonight: - - do a GS 1.3 beta and create a GS 1.3 branch, and put a release on zope.org - - point the GS external on the CMF 2.1 branch to the GS 1.3 beta tag - - run all unit tests for the CMF 2.1 branch - - tag CMF 2.1beta and release it If there are any concerns let me know ASAP. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGlk+ARAx5nvEhZLIRAgklAKCUY9/tD7WeMrEglp+WOfg+g84iJgCeIUxt xulLARQ4py0B8cIW9e2ScpY= =iahK -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
