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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Aspeli wrote:

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

My point is that imperative configuration creates a logically-insoluble
rats-nest:  Goedel's Law comes into play, because imperative stuff
induces ordering dependencies, which are irrelevant for purely
declarative stuff.

Plone's 'importVarious' was supposed to be a "temporary" hack when Rob
added it almost two years ago;  it should *still* die.  In the meantime,
it is the responsibility of the perpetrator to obey the Hippocratic
maxim, "first do no harm."


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

The examined part is a wart:  I missed earlier that you were advocating
its destruction.  It isn't logically any cleaner for the author of an
extension profile, however:  she still needs to do the Right Thing when
an unexpected step is run (e.g., one imported from another extension).

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

Note that the extension author's convenience was not highest in priority
in the design, which tries to make the integrators job easier.
Extension authors have to be extremely cautious, and may need to "clone"
steps (in the absence of dependencies).

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

That is a bug in CacheFu's handler:  "first do no harm" still applies.

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

You can't have it both ways:  either the handler runs after any
inspectiion, or only after importing the relevant extension profile
(which is what I would prefer).  If MyContentType's author *must* get
her cache.xml installed, then she needs to declare the handler (using
Products.CacheFu.exportimport.handle_whatever) in her own import_steps.xml.

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

A profile which includes configuration data for steps it does not itself
declare is asking for this kind of trouble.  In the absence of
dependencies, be explicit and add the steps.

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

I would rather spend effort on writing such XML dialects than on trying
to prevent imperative handler authors from shooting off their own feet.


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

iD8DBQFGr0i5+gerLs4ltQ4RAuW1AJ9u6hGaBrKivNtj0DtuJyKbRTFgPQCgjl9e
jmnNmVJLxK8RiCZjyl13z6A=
=owrx
-----END PGP SIGNATURE-----