[Zope-CMF] Re: GenericSetup extension profile import step mis-feature

Rob Miller ra at burningman.com
Tue Jul 31 13:21:02 EDT 2007


Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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.
> 
> 'importVarious' is a brutal hack:  better to focus efforts on making it
> disappear.  The entire point of the tool is to externalize configuration
> as declarative data in the profile;  accomodating imperative
> configuration is not something I care to support.
> 
> The 'upgrade' stuff Rob ported in from CPS is the only sane case I know
> of for imperative action.

while i agree with this in principal, i think the truth of the matter is that 
plenty of relatively inexperienced developers will be coding GenericSetup 
profiles.  these developers are the ones most likely to write imperative 
import steps (b/c they won't understand how to write a new XML parser, and it 
will seem like a lot of extra work compared to just twiddling a setting 
somewhere).  they are also the _least_ likely to understand the subtleties of 
GS's behaviour.

the problem is exacerbated by the symptoms; it's not that there will 
necesarily be problems running the profile in question.  it's when you try to 
import OTHER profiles that there will be problems, because these naively coded 
steps will be performing actions when they shouldn't be.

this has already shown itself to be the most misunderstood aspect of 
GenericSetup, i've had to explain the behaviour over and over again.  the 
documentation can be improved, sure, but we all know that people will be 
bitten by this no matter how clearly this issue is spelled out.

i'm pretty much in support of the proposal as it's evolved so far.  here's my 
understanding of it at this point:

- the import step registry will record the profile from which a given import 
step is included.  if multiple profiles include the same step in their 
import_steps.xml, they will both be recorded as related to that import step.

- when a profile is imported, only the import steps from the base profile and 
all transitively dependent profiles will be run.  (clearly this depends on 
actually finishing the dependency support.)

- when a profile is exported (or a snapshot is generated), all of the 
registered steps will be used.

this way, a naively coded import handler can only cause a problem when the 
profile it is associated with (or any other profile that explicitly depends on 
the problematic profile) is run.  writing imperative handlers should still be 
discouraged, but the damage that they can cause is contained.

-r



More information about the Zope-CMF mailing list