[Zope-CMF] Re: GenericSetup extension profile import step mis-feature

[Martin Aspeli]

yuppie-3 wrote:
> 
> Hi!
> 
> 
> The proposed solution doesn't work:
> 
> The ImportStepRegistry is not only used for imports - it is also used 
> for creating new 'import_steps.xml' files for exports.
> 
> Exported profiles are always base profiles, they have to specify *all* 
> import handlers used for creating the site.
> 

Right, that's fine. I think the current export functionality is right.
However, the current *import* functionality for extension profiles is
arbitrary and unpredictable.

What if we stored in the import step registry:

 - The setuphandler to call
 - The base or extension profile it came from

For an export operation, you just take the union of all the steps
(de-duplicated, of course).

For an import operation, you run:

 - All steps that came from the current base profile
 - All steps that came from explicit, transitive dependencies of the current
base profile (provided we get support for declaring profile dependencies)
 - All steps explicitly defined in the extension profile being run
 - All steps explicitly defined in transitive dependencies of the extension
profile being run (provided we get support for declaring profile
dependencies)

"Transitive" here means that if A depends on B and B depends on C, we run
steps from A, B and C.



> I can see two ways to specify available import steps:
> 
> 1.) 'import_steps.xml' is used as an index of available import steps. 
> That's the way it was used before extension profile support was added to 
> CMFSetup. It requires to maintain a lot of redundant information and a 
> way to identify and remove duplicate steps for exports.
> 

Yes... this sounds like what I am talking about above?



> 2.) The files in the profile determine which import steps are available. 
> This is the current behavior, but further changes would make this more 
> clear: Getting rid of 'import_steps.xml', using a global handler 
> registry instead. And adding new code that checks if a step is available 
> without actually running it.
> 

I'm not sure how this gets any clearer... e.g. how does the author of an
extension profile for an add-on product ensure that the steps he needs are
in the registry?

To me (and for a long time when I was using this blissfully unaware)
extension profiles really are separate entities that will generally be
applied in an uncontrolled order (unless we get explicit dependency support,
which would be really great). Flag files (be they empty boolean switches or
XML files with processing instructions) feel like a dirty way of dealing
with this unpredictability.

Martin
-- 
View this message in context: http://www.nabble.com/-Zope-CMF--GenericSetup-extension-profile-import-step-mis-feature-tf4190394.html#a11922157
Sent from the Zope - CMF list1 mailing list archive at Nabble.com.