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

[yuppie]

Hi!


Martin Aspeli wrote:
> yuppie-3 wrote:
>> 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)

???

Base profiles have per definition no dependencies. No?

>  - 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?

Not really. You are mixing both ways: Some import steps come from the 
registry (or are looked up in other profiles?), some from 
'import_steps.xml'.

>> 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?

The author of the add-on product is not responsible for this - just like 
he is not responsible for registering all adapters or utilities used by 
his product.

The author of the setup handler should add a ZCML file that registers 
the setup handler.

> 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.

Why is it more explicit to have a 'flag' import step in 
'import_steps.xml' or in 'import_steps.xml' of a dependency than a flag 
file in the current profile?


Cheers,

	Yuppie