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

[yuppie]

Hi Tres!


Tres Seaver wrote:
> 
> yuppie wrote:
>>
>> So the use cases for these DeltaProfiles are very limited. Using XSLT
>> would allow us to unify DeltaProfiles and ExtensionProfiles, providing
>> an automated way for creating ExtensionProfiles.
> 
> The major use case for "deltas" (no matter whether they do XSLT
> transforms or apply patches) is to permit re-applying local changes
> after an upgrade.  They aren't likely to be satisfactory as a mode for
> distributing add-ons, I think.

I agree that creating ExtensionProfiles for add-ons will never be a 
completely automated process. But it would be easier to polish a 
generated profile than writing ExtensionProfiles from scratch.

More important is that ExtensionProfiles can be applied to a profile, 
not just to a site. If that is not the case your use case (re-applying 
local changes after an upgrade) will not work.

I hope this example illustrates the problem:

Step 1: A Site is created using a base profile and some extensions.

Step 2: The site is customized TTW.

Step 3: An additional ExtensionProfile is applied.

Step 4: The site is further customized TTW.

Step 5: Now we want to upgrade the used profiles.


How would you create the necessary DeltaProfile? AFAICS this only works 
if we are able to create an uncustomized version of the profile 
combination used in that site. At no point you can create this 
uncustomized profile with a snapshot. And right now the only tool we 
have for combing profiles is the site itself.

So we either have to implement a machinery that allows to apply the 
existing ExtensionProfile format to base profiles directly or we have to 
switch to a new format for ExtensionProfiles. That new format should use 
a generic format like XSLT or diff.

Diffs are not made for manual editing and break easily if the base 
profiles are changed / updated.

> I would definitely like to break the requirement that extensions have to
> displace (even temporarily) the tool's import profile.  I would also
> like to work out how we might safely revert the application of an
> extension, as well as tracking dependencies among them.  I am *not*
> sanguine about using XSLT as the primary mechanism for describing an
> extension.

While I still believe XSLT would be the most powerful solution it is not 
a necessary part of my plan. My initial posting described an alternative 
approach:

If we split up the profile files in small pieces we can use layers and 
just override the pieces we want to change. This is not as fine grained 
as diffs or XSLT, but in exchange much simpler.


Cheers,

	Yuppie