[Zope-CMF] Re: GenericSetup extension profile import step mis-feature
Martin Aspeli wrote: > Hi guys, > > After a lot of "is-this-a-bug" type discussions with Rob and Wichert, > I've come to feel pretty strongly about the following: > > When you load an extension profile for the first time in GS, it looks to > see if it has any import steps (in import_steps.xml) that are not > already "known". If so, it adds them to the import step registry and > then runs all steps in the registry. > > Any time a profile (the same, or another one) is run subsequently, that > import step will be run too. In Rob's words, the import steps and the > profile that they came from (import_steps.xml-wise) get decoupled. > > We normally don't mind too much, because steps are run in the context of > a particular profile, and if that context has no matching XML file, > nothing is loaded. At least so we assume - there's of course nothing to > stop the setuphandler from having side effects even if the XML file is > not found. We *do* see a problem with importVarious-type hacks, though. > Here, people resort to checking for a "flag" (normally an empty text > file) to determine if the setuphandler should be run. > > I believe this is fundamentally Bad(tm) for three reasons: > > - People don't expect it to work that way. > - Authors of setuphandlers have to be a lot more careful about having > side effects on entirely alien packages. > - It's impossible to predict which steps actually get run for an > extension profile. > > Say, for example, that I wrote extension profile Y and I wanted to use > an import handler used in extension profile X. If X had been run (or in > fact, looked at under the Import tab, the registry filling happens as > soon as you look at a profile there, even without running it) at least > once, then it would get attempted for Y as well. If the appropriate XML > or flag file was found it'd be run. > > But there is no way for Y to know that X was run (or looked at). In > fact, it may be that users of Y do not want X to be loaded at all. > > The only predictable way for Y's author to run said import step is to > explicitly list a setuphandler from X's package in Y's own > import_steps.xml. > > I cannot see a good use case for the current behaviour, and it causes a > lot of confusion (either "why was this step run again?" or "why wasn't > this step run?"). Having to have flag files for pure-python > setuphandlers is also pretty hacky (even if such handlers themselves are > a bit hacky, but sometimes unavoidable). One example where the current behavior makes sense is when you write an add-on product which wants to install itself into a standard Plone site and change the settings of the Archetypes tool. The import handler for the Archetypes tool is only specified in the extension profile for Archetypes and not in the Plone base profile. It is however always installed into a Plone site via an import various step. I think this kind of decoupling the different profiles into the packages they came from is a sensible idea. In order for that to work reliable we need to have some profile dependency support, though. When we would have that I would extend your idea in the following way: > The only sane behaviour, IMHO, is this: > > - When importing a base profile, only steps from the base profile are run. > > - When importing an extension profile, only steps from the *current* > base profile and any additional steps explicitly defined in the > *selected* extension profile (via an import_steps.xml file) are run. In both cases all the steps from any (recursively) defined dependencies are run as well. So the Plone Base profile would depend on the Archetypes extension profile (as well as the other half a dozen we install manually right now) and you could always assume the Archetypes tool import step to be present. For an add-on X it can decide to depend on Y and thus re-use all of their import steps as well, without having to specify the handler itself. > No steps are ever implicitly pulled in from other extension profiles, > and switching base profiles resets the base set of steps that are run > for any extension profile. > > Another solution (better than the current behaviour, less good imho than > the solution above) would be to load all steps from all profiles at Zope > startup, when the profile registry is populated, so that all steps are > always run if a package registering a new step is installed. This still > means having lots of flag/file-checking and could be quite inefficient. This is really bad. That way if there is some experimental profile registered somewhere it would get loaded automatically. So as soon as I have one broken import step somewhere I would have no chance to exclude it. The registration of an import step should still be an explicit task. > What do you think? Is there a sane use case for the current behaviour? Apart from the decoupled but guaranteed-to-be-there extension profiles I cannot think of any. Hanno _
[Zope-CMF] GenericSetup extension profile import step mis-feature
Hi guys, After a lot of "is-this-a-bug" type discussions with Rob and Wichert, I've come to feel pretty strongly about the following: When you load an extension profile for the first time in GS, it looks to see if it has any import steps (in import_steps.xml) that are not already "known". If so, it adds them to the import step registry and then runs all steps in the registry. Any time a profile (the same, or another one) is run subsequently, that import step will be run too. In Rob's words, the import steps and the profile that they came from (import_steps.xml-wise) get decoupled. We normally don't mind too much, because steps are run in the context of a particular profile, and if that context has no matching XML file, nothing is loaded. At least so we assume - there's of course nothing to stop the setuphandler from having side effects even if the XML file is not found. We *do* see a problem with importVarious-type hacks, though. Here, people resort to checking for a "flag" (normally an empty text file) to determine if the setuphandler should be run. I believe this is fundamentally Bad(tm) for three reasons: - People don't expect it to work that way. - Authors of setuphandlers have to be a lot more careful about having side effects on entirely alien packages. - It's impossible to predict which steps actually get run for an extension profile. Say, for example, that I wrote extension profile Y and I wanted to use an import handler used in extension profile X. If X had been run (or in fact, looked at under the Import tab, the registry filling happens as soon as you look at a profile there, even without running it) at least once, then it would get attempted for Y as well. If the appropriate XML or flag file was found it'd be run. But there is no way for Y to know that X was run (or looked at). In fact, it may be that users of Y do not want X to be loaded at all. The only predictable way for Y's author to run said import step is to explicitly list a setuphandler from X's package in Y's own import_steps.xml. I cannot see a good use case for the current behaviour, and it causes a lot of confusion (either "why was this step run again?" or "why wasn't this step run?"). Having to have flag files for pure-python setuphandlers is also pretty hacky (even if such handlers themselves are a bit hacky, but sometimes unavoidable). The only sane behaviour, IMHO, is this: - When importing a base profile, only steps from the base profile are run. - When importing an extension profile, only steps from the *current* base profile and any additional steps explicitly defined in the *selected* extension profile (via an import_steps.xml file) are run. No steps are ever implicitly pulled in from other extension profiles, and switching base profiles resets the base set of steps that are run for any extension profile. Another solution (better than the current behaviour, less good imho than the solution above) would be to load all steps from all profiles at Zope startup, when the profile registry is populated, so that all steps are always run if a package registering a new step is installed. This still means having lots of flag/file-checking and could be quite inefficient. What do you think? Is there a sane use case for the current behaviour? Martin -- Acquisition is a jealous mistress ___ 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 Sun Jul 29 12:00:00 2007 UTC to Mon Jul 30 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: Sun Jul 29 21:30:22 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005800.html Subject: OK : CMF-1.5 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Sun Jul 29 21:31:55 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005801.html Subject: OK : CMF-1.5 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Sun Jul 29 21:33:27 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005802.html Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Sun Jul 29 21:34:58 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005803.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Sun Jul 29 21:36:29 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005804.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Sun Jul 29 21:38:02 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005805.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Sun Jul 29 21:39:34 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005806.html Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Sun Jul 29 21:41:09 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005807.html Subject: OK : CMF-2.1 Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Sun Jul 29 21:42:40 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005808.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Sun Jul 29 21:44:11 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005809.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Sun Jul 29 21:45:42 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005810.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] 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
