[Zope-CMF] Re: [dev] CMFSetup roadmap?

[Tres Seaver]

yuppie wrote:
> Hi!
> 
> 
> Martijn Pieters wrote:
> 
>> There are two usage scenarios for add-on Products:
>>
>> 1) Using add-on Products plus CMFSetup for a custom site setup you want
>>    to reproduce easily.
>>
>> Site builders can create the correct profile files already with the 
>> current CMFSetup tool, by including add-on Products import and export 
>> steps by hand. It would be handy if there was a TTW UI to add steps so 
>> that one can run an initial export to create a profile one can check 
>> into CVS.
> 
> 
> Yes. And I hope writing new import/export handlers will become easier in 
> the long run.
> 
> 
>> 2) Including add-on Products' tools and their setup in a default
>>    installation of a CMFDefault Site (or a Plone site if Plone chooses
>>    to use CMFSetup)
> 
> 
> This is the scenario I had in mind and what's needed to replace the old 
> setup machinery. Add-on products should ship with XML files, not with 
> install scripts, FTIs and preconfigured tools.
> 
>> My original CMFSetup product used a runtime registry to manage 
>> dependencies and add-on steps centrally. In the CMF 1.5 refactoring, 
>> this registry has been replaced by 2 XML files in the profile, which 
>> makes it hard for add-on products to add their steps by default for 
>> easy alteration of a default CMFsetup.
>>
>> My original CMFSetup also included support for multiple layers that 
>> could be run in succession; each step would loop through the layers 
>> and apply the configurations. Extra products could then add a layer 
>> for the 'tools' install step that just included their own new tools 
>> and configurations, or even undo default configuration changes done by 
>> earlier layers.
>>
>> If add-on products want to enable installation into a stock CMF 
>> Default site (or a Plone site if Plone were to use CMFSetup), then I 
>> think that supporting layering again would be the best way to go; 
>> additional products would only have to include additional XML files 
>> for the changes they need to make for their default setup. A central 
>> registry could then manage what profiles are available, and what 
>> layers are enabled.
> 
> 
> That sounds reasonable. But if I did get Tres right, there was a reason 
> why he didn't check in that code. I just did never understand how things 
> could work without a machinery like that.

The current machinery allows for a redistributable, on-disk profile to 
govern site configuration;  it is *not* aimed at allowing arbitrary 
third-party extensions to an existing profile.

The major problem is that profiles represent policy, and add-on products 
can't possibly be smart enough to know the policy.  We might extend the 
setup machinery to allow products to register "available profile 
fragments", which would require an explicit gesture from the site admin 
to be incorporated into the current site config.

Note that after the site admin modifies the site config in *any* way, 
she should plan to snapshot / export the modified config to a new 
profile, which then represents the policy in effect.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com