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

[Martin Aspeli]

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.


Aha - so it seems was confused :) So, to be clear, "run all import steps"
will only apply to the last selected "active" profile, even if that's an
extension-profile?

I guess we'd need to switch active profiles around from time to time, e.g.
if we were selecting a profile for un-install or re-install.

The point of not losting customisations is really important. However, I'd
also like to have a way to force the profile application to override
customisations, when you explicitly want a "clean install". 


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

I guess. Even if that isn't too sensible, it may be necessary for example to
control the order in which updates happen.



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

+1, so long as we acknowledge that sometimes it may be necessary to write
some custom python code ala importVarious, if only due to time constraints.
Writing a generic parser must always be harder than writing a line of code
to configure something. :)



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

I have those concerns too ;)

Thanks for the update. So long as we keep the "trying out a new product" use
case in mind and focus on making it as easy to make import handlers, I think
we're very much on the same page.

By the way - two other things I brought up in the post to plone-dev was:

 - We need some way of exposing to the user the *version* of the profile
being applied, i.e. the version of the product. "You have Foo version 1.0
installed, but version 2.0 on the filesystem. Do you want to upgrade?"

 - We need some way of expressing dependencies between profiles, so that
installing Foo also installs Bar. It should be possible to do optional
dependencies, too, so that Foo installs Bar if Bar is available, but doesn't
fail if it's not.

Martin
-- 
View this message in context: http://www.nabble.com/-dev--RFC%3A-rethinking-GenericSetup-extension-profiles-tf1996759.html#a5489196
Sent from the Zope - CMF list2 forum at Nabble.com.