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

[yuppie]

Hi!


Since CMF 1.5.1 CMFSetup/GenericSetup supports extension profiles. They 
are quite useful, but their current format has some fundamental issues:

- Only a site instance can interpret that format and merge an extension 
profile into a base profile. The extension profile has to be applied in 
a special mode (non-purging) and needs some special update directives 
(like 'remove' or 'insert-before').

- We have no way to specify dependencies between profiles.


That has serious consequences:

1.) Extension profiles are hard to create and maintain

You need a lot of knowledge about the import handlers. Only if you know 
how their non-purging mode is implemented and which update directives 
are available you can write good extension profiles. There are no tools 
that help you to create extension profiles.

2.) Sites using extension profiles are hard to create and maintain

You have to know which profiles depend on other profiles. It's hard to 
control the order in which profiles are applied. The Comparison tab 
becomes useless if the site uses several extensions that are not part of 
the 'initial_configuration' snapshot. (Sometimes I create a new site to 
get a clean snapshot of the applied profiles and delete that site again. 
A quite expensive procedure.) A snapshot contains no information which 
original profiles it 'contains'. The tool has no control on the applied 
profiles. There is no way to uninstall profiles.


And now forget everything you know about extension profiles. Imagine 
they were like this:

Extension profiles describe how to transform base profiles. They know 
which profiles they can transform (AKA dependencies). They are applied 
to an other profile, *not* to the site.

Only complete profiles (base profiles or extended base profiles) are 
applied to the site. The handlers only need to understand complete 
configuration files.

The setup tool knows how to merge profiles without modifying the site. 
You can compare your snapshot with any valid combination of profiles you 
like. There might even be a function that searches for the profile 
combination that has the smallest diff to your snapshot and finds this 
way the best dependencies list.


And now imagine we have a tool that can *create* extension profiles 
based on the current customizations.

This would allow to provide many new features:

- customization snapshots:
Snapshots would just contain the customizations and a list of 
dependencies, not a complete base profile.

- install/uninstall:
Basically any setup change is applied by recreating the site from 
scratch. At least for some expensive to create items like indexes we 
have to make sure we don't delete/recreate them if they were not 
modified. Uninstall would be no different procedure, we just don't 
reapply a specific profile.

- migrations:
There are different kinds of migrations. Updates in the base profiles 
would be applied using the install procedure.


I can see 2 different ways to change the extension profile format:

1.) Splitting configuration files in many small files

This would also change the format of base profiles. Extension profiles 
are simple layers and files in higher layers override files in lower layers.

pros: easy to implement; easy to understand

cons: requires new base profiles and modified setup handlers; changes 
can only be as fine grained as the file structure

2.) Using XSLT

For applying XSLT files we can use existing XSLT libraries. I'm not 
aware of any generic library that allows to create XSLT files based on 
the difference between two XML files. But the GenericSetup profiles just 
use a subset of XML so it would be much easier to write a special tool 
for GenericSetup diffs than writing a general XML diff tool.

pros: works with current base profiles and setup handlers

cons: depends on the necessary XSLT tools (I guess for the diffs we have 
to write them ourselves)


What do you think?


Cheers,

	Yuppie