[Zope-CMF] Re: Base and Extension profiles

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

yuppie wrote:
> Hi!
> 
> 
> Rob Miller wrote:
>> it may be argued that extension profiles were never meant to be used as 
>> a means for product installation.  so far, however, this strategy has 
>> proved effective, and IMO is considerably nicer than what we had 
>> before.  whether or not it was the original intent, it has become a 
>> valuable use case, and i suspect will continue to grow in usage.
> 
> No need to argue. I'm quite sure I remember my intentions ;) 
> GenericSetup was called CMFSetup and extension profiles were called 
> add-on profiles at that time, but this is the original proposal: 
> http://mail.zope.org/pipermail/zope-cmf/2005-March/021963.html
> 
> Supporting the installation of add-on products was exactly the reason to 
> propose this feature.
> 
> Nevertheless I'm not happy with the current implementation of extension 
> profiles. Using the 'skip purge' mode was the easiest way to implement 
> them, but it opened a can of worms:
> 
> GenericSetup is not CMFQuickInstaller. Its strength is to manage states, 
> not state change procedures. In 'skip purge' mode GenericSetup behaves 
> more like a traditional installer. It modifies the site configuration 
> step by step. This encourages people to think in a procedural way. They 
> write importVarious steps and more update directives for the XML files. 
> Trying to use profiles like install scripts GenericSetup becomes more 
> and more complicated, loosing the focus on states.

We sprinted on GenericSetup this past week, and hammered on this problem
a bit.  One thing we tried to do was to break apart "upgrade" processing
from "import" processing:

  - Upgrades are procedural, messy, and therefore "dangerous".  They
    also need protections so that they don't run more than once, or
    maybe at all in some cases.

  - Imports are state-oriented, declarative, and therefore "safer".
    They should be re-runnable at will.

In order to implement this divide, we landed the "upgrade" extension
(with Nuxeo's permission) from CPS.  We also broke up the confusing /
dangerous UI of the "Properties" (now "Profiles") tab, making it clear
that the "baseline" profile was not normally replacable, and making it
possible to import extensions without the dangerous "replace the
baseline, import, put back the baseline" dance.

This work is available on a branch:

  svn+ssh://svn.zope.org/GenericSetup/branches/tseaver-bbq_sprint

We (the sprint team, see
http://www.openplans.org/projects/bbq-sprint/generic-setup-report) would
like feedback on that branch, before proposing that we merge it to the
trunk.

> The GenericSetup way to do this would be transforming profiles, not 
> sites. Unfortunately implementing this kind of extension profile depends 
> on good diffs. Delta profiles based on unified diffs will not work for 
> this use case, they are not flexible enough. A solution might be the XML 
> diffs Matt offered to contribute: 
> http://mail.zope.org/pipermail/zope-cmf/2007-February/025570.html

I don't yet understand how such diffs would be represented, much less
implemented.  I do agree that the current line-oriented diff format is
probably too fragile to use as the basis for a DeltaProfile,
particularly if we continue to generate export XML using ZPT (an etree /
objectify model would likely produce more normalized output).


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGABJ/+gerLs4ltQ4RAg0dAJ46pshif90RkP33+xrcB+q12hVolQCgv7g6
2oxiFIolhcL/cYCStgzD/cw=
=EeA+
-----END PGP SIGNATURE-----