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

[Martin Aspeli]

Tres Seaver wrote:
> 
> '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.
> 

I think that's a bit puritanical. Sometimes it's just not possible to have
declarative configuration for anything, either for time or complexity
reasons. There will be setup tasks that can only feasibly be achieved in an
imperative way, and need to run during the installation of a product.



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

All steps of what?

The way it works now, it's "all steps of any base or extension profile that
has ever been examined by the user or imported", which is not terribly
predictable.



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

That makes a lot of sense for export or creation of a new base profile.
However, due to the lack of predictability of what has actually been grafted
in to date, third party product authors writing an extension profile will
never be able to safely depend on steps from anything else than a
"supported" base profile (or explicit dependencies if and when we get
those).



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

It's not about files, it's about the registry.

Here's an example from Plone:

 - Product CacheFu has an extension profile that declares a new import
handler for the Cache Settings tool/control panel. Let's say it creates a
handler for the cache.xml file.

 - Product MyContentType wants to configure caching, with a cache.xml file.

Now, if CacheFu has been looked at once or imported, cache.xml is run.
CacheFu may or may not be in a sane state at the point (e.g. if you just
looked at the profile, you may get an error because the setuphandler is
expecting CacheFu to be installed when it isn't). 

Equally, if CacheFu isn't installed and was never looked at, the cache.xml
file is never run, even though the product author probably intended it to
be.

Of course, there may be a good reason to have cache.xml not be processed if
CacheFu isn't installed, but it's still unpredictable. The only way I can
make it predictable would be if I explicitly declared a dependency on this
profile and/or I explicitly declared a dependency on the product that
provided it.

In other cases, the setuphandler may be more generic and thus not really
depend on e.g. a tool being installed. In that case, it may be very
desirable to have the XML file always be processed, but it won't happen
unless the product with the setuphandler was installed or looked at once.



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

Yeah, you're right.


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



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

I wish I could, but I've yet to come across a non-trivial product where I
didnt need at least a tiny bit of imperative configuration. Most often, it's
because things I depend on don't yet have (sufficiently expressive) XML
configuration for the option I need to set. I don't really want to invent my
own XML syntax for third party products all the time.

Martin
-- 
View this message in context: http://www.nabble.com/-Zope-CMF--GenericSetup-extension-profile-import-step-mis-feature-tf4190394.html#a11924624
Sent from the Zope - CMF list1 mailing list archive at Nabble.com.