[Zope-CMF] Re: Modifications using GS profiles

[yuppie]

Hi Tres!


Tres Seaver wrote:
> yuppie wrote:
>> Tres Seaver wrote:
>>> yuppie wrote:
>>>> Tres Seaver wrote:
>>>
>>> If we had the upgrade machinery in place, we could scrap non-purging
>>> mode altogether -- its purpose is to allow for "controlled" application
>>> of changes to existing configuration without full replacement.
>>> [...]
>> Well. If we don't use the non-purging mode we can't write changes as 
>> profile snippets. Should upgrade steps always be implemented in pure 
>> Python without using any XML files?
> 
> I would say that the "execute-while-parse" model of our current profile
> import driver is wrong for upgrades, but it would be possible.  The
> upgrade step could do the checking that a given "upgrade-only" extension
> should be imported, and then import it (perhaps passing 'no_purge' as a
> flag).
> 
> Meanwhile, we would disable / remove any UI for setting that flag
> outside an upgrade.

I removed the UI for setting that flag long ago. But extension profiles 
are always applied in non-purging mode, so the upgrade machinery doesn't 
help us to get rid of that mode.

I also would like to get rid of it, but that is only possible if we have 
a delta profile machinery that supersedes extension profiles.

>> The CMF 2.1 branch is not as stable as it should be. Adding the 'upgrade 
>> steps' feature might be low risk, but the other changes on the sprint 
>> branch look more risky to me. I'm a bit afraid merging them will 
>> destabilize the 2.1 branch further.
> 
> I don't think so.  The other changes split out the UI for setting the
> baseline profile (ordinarily done only at site creation) and showing
> available extensions.  I think the cleanup there is highly unlikely to
> cause instability:  the only change is that we no longer require (or
> even allow) people to set extension profiles as "faux" baselines in
> order to import them.

If you say so, I withdraw my objections.


Cheers,

	Yuppie