-----BEGIN PGP SIGNED MESSAGE-----
> 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:
> 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:
We (the sprint team, see
like feedback on that branch, before proposing that we merge it to the
> 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:
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 Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v188.8.131.52 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests