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
