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.

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



Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to