I'd like to discuss possible improvements to have profile extensions check some dependencies. This will require a way to express dependencies, which in the general case can be extremely complex -- but we probably don't need that.

Use cases

1. When installing CMFDefault:default, I'm offered the extensions SQLDiscussions and BlogDiscussions, which both change the portal_discussions tool but are incompatible between each other.

  => There may be conflicts between extensions.

2. At a customer I'm installing CPS:default, with the standard extension CPS:simple_mode (which doesn't make sense with CMF), and finally the customer-specific extension SomeCustomer:default. Just selecting "Somecustomer:default" should get all the required profiles.

  => An extension may have required profiles, and this can be cascaded.

3. CPSCalendar:default was coded with requiring CMFDefault:default but actually CPS:default can also work with it, even if CPSCalendar doesn't know about it.

  => A profile may say that it accepts an extension even if the
     extension has explicit requirements and the profile isn't listed
     in them.


Today a profile can be either BASE or EXTENSION.

I'd like to extend this value to be one of:

 - None
    Which means a toplevel profile, equivalent to BASE

 - {}
    Which means a simple extension profile, equivalent to EXTENSION

 - {'requires': ('CMFDefault:default', 'CPS:default')}
    Which means that this profile can only be installed with
    one of the listed profiles.
    (Should maybe be 'requires_any' to be clear.)

 - {'conflicts': ('Bar:bar',)}
    Which means that this profile cannot be installed with any
    of the listed profiles.

 - {'provides': {'Foo': ('Bar', 'Baz')}}
    Which says that this profile can pose as Foo in package Bar and
    Baz's requirements. Maybe () could mean for all packages. Maybe
    this should also be taken into account by conflicts?

Comments? I'm pretty sure this can be improved in term of expressing the dependencies, but the basic use cases are real for me.

One of the challenges would be the user interface, of course.


Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
Zope-CMF maillist  -  Zope-CMF@lists.zope.org

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

Reply via email to