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

[Tres Seaver]

-----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.

> 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.

Authors of setup handlers shouls be *extremely* careful, and should not
be running unless they have information in the profile to be applied.

>   - It's impossible to predict which steps actually get run for an 
> extension profile.

Yes it is:  *all* steps will get run, and will consult the profile to
see whether they have configuration to apply.

> 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.

That is by design.  Once an import step is grafted into the baseline, it
is part of the site's configuration for ever.  Resetting the baseline
profile (a drastic step) is the only way to wipe it out.

> 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.

You'd better make this un-abstract:  the presence of the enabling files
in the profile being imported *is* the signal that those steps should be
active.

> 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).

I doubt they are unavoidable:  rather, I think nobody has wanted to
think about reworking them.  Not the same thing atall.

> The only sane behaviour, IMHO, is this:
> 
>   - When importing a base profile, only steps from the base profile are run.

Do you mean when setting a new baseline?  Otherwise, -1:  snapshots, for
instance, are "baseline" profiles, and represent accumulated steps.

>   - 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.

There is nothing implicit about this:  those steps are part of the
configured state of the site.  If the profile-being-imported has
configuration for them, they should do their stuff;  otherwise, they
should pass.

> 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?

As above:  quit doing imperative configuration, and the problems go away.



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGrzp7+gerLs4ltQ4RApbLAKCvsbT138qXw0yQx0T44OY4gWlX+QCfeJWU
UU0/RqvTuDupH0hTf4O0PvA=
=eWYo
-----END PGP SIGNATURE-----