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.
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:
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests