[Zope-CMF] Re: [dev] RFC: rethinking GenericSetup extension profiles

[yuppie]

Hi Martin!


Martin Aspeli wrote:
> 
>> - The procedure I have in mind depends on the ability to create 
>> customization snapshots. As a first step the setup tool would create 
>> this snapshot. In the next step it would combine all dependencies of 
>> that snapshot minus uninstalled extensions plus new extensions. The 
>> result is a profile that contains the latest data of all selected 
>> profiles plus the customizations from the snapshot. This profile would 
>> be used to reset the site.
>>
> 
> Bearing in mind that my understanding is not completely solid, the option I
> keep thinking we need is to say "run all import steps, but only for this one
> extension profile". I have a workflows.xml and a types.xml and whatever else
> in my extension profile for my product. I'd like to uninstall or re-install
> or install workflows and types *for my product*, but I'm not interested in
> evaluating every workflows.xml and types.xml in every active profile
> everywhere (e.g. those that came with Plone or CMF or some other product),
> lest they'd changed or I'd changed them and didn't want my changes stomped
> on. Even though the actual import step is defined in another product (e.g.
> CMFCore) I assume it'd be possible to simply not include steps for other
> profiles?

The concept of import steps is confusing because it was invented before 
extension profile support was added. Originally an import step 
represented a piece of the profile. The handler property just provided 
the information which handler to use for this piece of the profile. That 
did no longer work with extension profiles. Now an import step just 
registers an handler.

Only the last selected profile is active. Normal import steps depend on 
configuration files and do nothing if the active profile does not 
contain related files. importVarious steps have to simulate that 
behavior by testing if they are already applied. If the import handlers 
follow those rules (CMF handlers do) only the profile *for your product* 
is applied. Running all steps just means that all handlers try to find 
related files in the active profile and apply them *if* they exist.

So your example should work right now. My proposal would mean that 
everything is reset, but without loosing customizations. So while the 
procedure would be much more expensive the result should be similar.

>> - I don't know if we really need a way to reset specific products. 
>> AFAICT the more common use case is to reset specific objects like tools. 
>> I'd prefer a tab on the object that allows to load preconfigured 
>> settings instead of using the setup tool for that.
>>
> 
> This doesn't resonate with my experience from Plone, if I'm understanding
> you correctly. I agree that some way of resetting individual tools may be
> useful, but that's still very low level. If Joe Average downloads
> CMFCrazyPollingProduct, he may install it, and need to un-install it
> cleanly.

This is the normal uninstall procedure I described in my last mail.

> He may also need to re-set it if he messed up its configuration or
> maybe he's the developer and wants to test the effects of a clean
> re-install.

Well. You can't always tell which customizations belong to which 
product. But after uninstalling a product customizations of related 
objects will fail if they no longer exist. So we if we uninstall and 
reinstall a product the effect should be similar to a reset.

> Or, if the product is updated, he may need to re-run its
> installation.

Do you mean you want to switch to the latest version of a specific 
profile but not of all profiles?

>> - While I hope we can get rid of importVarious it would be less 
>> dangerous to use if only complete profiles are applied to the site.
>>
> 
> I suppose, except if I'm trying to just install product X, running some
> (potentially destructive) importVarious from some other unrelated product
> still seems risky.

It's still a hack. But I think we should focus on making writing 
handlers easier instead on making it easier to work around writing 
handlers. The changes I propose make it easier to write handlers. 
Writing handlers for PropertyManagers is already quite easy and generic 
support for Zope 3 schemas could be added.

> Perhaps its FUD, but essentially re-creating a site each time you do an
> incremental update (e.g. install a new product) seems really risky to me. A
> bad product install can sometimes mess up that product - if you started
> getting strange exceptions (and GS exceptions aren't always that easy to
> debug, I've found) from somewhere deep within an unrelated product, that
> could be pretty scary too.

I don't share those concerns. I'm more concerned about artifacts left 
behind by imperfect uninstall routines.


Cheers,

	Yuppie