[Zope-CMF] Re: [dev] RFC: rethinking GenericSetup extension profiles

2006-07-25 Thread Martin Aspeli
yuppie wrote: Aha - so it seems was confused :) So, to be clear, "run all import steps" will only apply to the last selected "active" profile, even if that's an extension-profile? Yes. The ImportContext has only access to the last profile selected. What still might happen with broken import h

[Zope-CMF] Re: [dev] RFC: rethinking GenericSetup extension profiles

2006-07-25 Thread yuppie
Hi Martin! Martin Aspeli wrote: Aha - so it seems was confused :) So, to be clear, "run all import steps" will only apply to the last selected "active" profile, even if that's an extension-profile? Yes. The ImportContext has only access to the last profile selected. What still might happen

Re: [Zope-CMF] [dev] RFC: rethinking GenericSetup extension profiles

2006-07-25 Thread Martin Aspeli
The concept of import steps is confusing because it was invented before extension profile support was added. Originally an import step represented a piece of the profile. The handler property just provided the information which handler to use for this piece of the profile. That did no longer

[Zope-CMF] Re: [dev] RFC: rethinking GenericSetup extension profiles

2006-07-25 Thread yuppie
Hi Martin! Martin Aspeli wrote: - The procedure I have in mind depends on the ability to create customization snapshots. As a first step the setup tool would create this snapshot. In the next step it would combine all dependencies of that snapshot minus uninstalled extensions plus new exten

Re: [Zope-CMF] [dev] RFC: rethinking GenericSetup extension profiles

2006-07-25 Thread Martin Aspeli
yuppie-2 wrote: > > GenericSetup uses a completely different approach than > CMFQuickInstaller. It is focused on states, not on changes. > Indeed. From having used it recently, it just seems to be an easier way of working, so I'm trying to find out how we can meet the use cases that CMFQI mee

Re: [Zope-CMF] Re: [dev] RFC: rethinking GenericSetup extension profiles

2006-07-25 Thread Martin Aspeli
yuppie-2 wrote: > > GenericSetup uses a completely different approach than > CMFQuickInstaller. It is focused on states, not on changes. > Indeed. From having used it recently, it just seems to be an easier way of working, so I'm trying to find out how we can meet the use cases that CMFQI mee

[Zope-CMF] Re: [dev] RFC: rethinking GenericSetup extension profiles

2006-07-25 Thread yuppie
Hi Martin! GenericSetup uses a completely different approach than CMFQuickInstaller. It is focused on states, not on changes. The early versions of GenericSetup (FKA CMFSetup) didn't even have extension profiles and importVarious handlers. I invented those hacks to give GenericSetup more mo

[Zope-CMF] CMF Collector: Open Issues

2006-07-25 Thread tseaver
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open jens - "CachingPolicyManager: Support OFS.Cache.CacheManager", [Accepted] http://www.zope.org/Collectors/CMF/408 mhammond - "Windows Developm

[Zope-CMF] Re: [dev] RFC: rethinking GenericSetup extension profiles

2006-07-25 Thread Martin Aspeli
yuppie wrote: Since CMF 1.5.1 CMFSetup/GenericSetup supports extension profiles. They are quite useful, but their current format has some fundamental issues: I posted something in a similar vein to this on plone-developers last night, about using GenericSetup profiles for product installation

[Zope-CMF] [dev] RFC: rethinking GenericSetup extension profiles

2006-07-25 Thread yuppie
Hi! Since CMF 1.5.1 CMFSetup/GenericSetup supports extension profiles. They are quite useful, but their current format has some fundamental issues: - Only a site instance can interpret that format and merge an extension profile into a base profile. The extension profile has to be applied in