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

Martin Aspeli optilude at gmx.net
Tue Jul 31 03:29:11 EDT 2007


Hanno Schlichting wrote:

> One example where the current behavior makes sense is when you write an
> add-on product which wants to install itself into a standard Plone site
> and change the settings of the Archetypes tool. The import handler for
> the Archetypes tool is only specified in the extension profile for
> Archetypes and not in the Plone base profile. It is however always
> installed into a Plone site via an import various step.

Mmm, well that's another problem: Installing one profile during 
installation of another also does not work reliably (I believe Rob was 
working on a generic dependency solution for this).

> I think this kind of decoupling the different profiles into the packages
> they came from is a sensible idea. In order for that to work reliable we
> need to have some profile dependency support, though.

Right. You could extend my argument to include "and those extension 
profiles explicitly marked as dependencies of the current base profile 
or the extension profile being installed".

> When we would have that I would extend your idea in the following way:
> 
>> The only sane behaviour, IMHO, is this:
>>
>>  - When importing a base profile, only steps from the base profile are run.
>>
>>  - When importing an extension profile, only steps from the *current*
>> base profile and any additional steps explicitly defined in the
>> *selected* extension profile (via an import_steps.xml file) are run.
> 
> In both cases all the steps from any (recursively) defined dependencies
> are run as well.

Yes.

> So the Plone Base profile would depend on the Archetypes extension
> profile (as well as the other half a dozen we install manually right
> now) and you could always assume the Archetypes tool import step to be
> present.
> 
> For an add-on X it can decide to depend on Y and thus re-use all of
> their import steps as well, without having to specify the handler itself.
> 
>> No steps are ever implicitly pulled in from other extension profiles,
>> and switching base profiles resets the base set of steps that are run
>> for any extension profile.
>>
>> Another solution (better than the current behaviour, less good imho than
>> the solution above) would be to load all steps from all profiles at Zope
>> startup, when the profile registry is populated, so that all steps are
>> always run if a package registering a new step is installed. This still
>> means having lots of flag/file-checking and could be quite inefficient.
> 
> This is really bad. That way if there is some experimental profile
> registered somewhere it would get loaded automatically. So as soon as I
> have one broken import step somewhere I would have no chance to exclude
> it. The registration of an import step should still be an explicit task.

Yeah, good point. :)

>> What do you think? Is there a sane use case for the current behaviour?
> 
> Apart from the decoupled but guaranteed-to-be-there extension profiles I
> cannot think of any.

Explicit being better than implicit and all that. :)

Martin


-- 
Acquisition is a jealous mistress



More information about the Zope-CMF mailing list