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

[Martin Aspeli]

yuppie-3 wrote:
> 
> 
>> 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?
> 

Probably, though in Plone, for example, it'd be very useful to be able to
say "when installing Plone, please also install extension profiles from
Archetypes and CMFEditions", where those are dependencies. That's mostly
from a code-management point of view, though. Anyway, that functionality
doesn't exist yet, so let's not quibble.



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

I think "looked up in other profiles" is more predictable for imports, where
"other profiles" means "the current base profile and any explicit
dependencies, plus the one being installed right now".



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

Okay, that's different, now we have an instance-global registry. That may
make sense, though Tres pointed out you'd need to not run unexpected export
steps on export, for example.



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

The flag file is magical. It's not used for anything.

But it's the reverse case that's the problem: As an author of product Y with
an extension profile, if I want to make sure I run steps that were in
setuphandlers in product X, I don't have a sane way of making sure they get
run. They *may* get run if the user looked at and/or ran the import steps
for X, but I have no way of controlling that.

Therefore, I have to be explicit and include those steps. Therefore, having
import steps from extension profiles be additive is an unpredictable
feature. Therefore, why require magic flag files?

Obviously, that goes away with an instance-global setuphandler registry.
Then we still have flag files, but at least it's predictable.

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