[Zope-CMF] GenericSetup: Apply profile dependencies only once

[Maurits van Rees]

Hi yuppie,

Op 09-09-15 om 11:43 schreef yuppie:
> Hi Maurits,
>
> Maurits van Rees wrote:
>> Dependency profiles from metadata.xml that are already applied, are not
>> applied again. Instead, its upgrade steps, if any, are applied. In code
>> you can choose the old behavior of always applying the dependencies, by
>> calling runAllImportStepsFromProfile with always_apply_profiles=True. Or
>> you can choose to be happy with any applied version and ignore any
>> upgrade steps, by using upgrade_dependencies=False. Note that these
>> arguments cannot both be True.
>
> assuming that profiles always depend on the latest versions of specified
> profiles is fine. But wouldn't it be better to make upgrading existing
> profiles an explicit extra step in the UI? Does it make sense to upgrade
> only the dependencies, not other applied profiles?

Basically I am thinking: we used to reapply the entire profile, let's 
instead not do nothing at all, but meet halfway: run the upgrade steps.

I guess we could add an extra option in the UI, making use of these new 
options.  The user already has the option 'Include dependencies' there, 
default Yes.  An extra option might be 'Apply upgrade steps of already 
applied profiles instead of reapplying them completely', with default 
Yes.  We might then need to make it possible to select all possible 
combinations of what I now made possible.  Danger is that it gets 
confusing for the end user (well, site admin).

Unrelated profiles should be left alone.  Possibly a method 
'applyAllUpgradeStepsOfAllProfile' could be useful, with a big button on 
the Upgrades tab.  But not in this pull request.

> I would just raise an error if the dependencies are not up to date and
> ignoring the problem or running upgrades or re-applying profiles is not
> explicitly specified. If only one option is allowed, why not using one
> argument? outdated_dependencies=None|ignore|upgrade|reapply

Maybe 'upgrade_strategy=...'  It *does* mean one keyword argument less, 
which can be nice.

> But I can also live with your solution. As long as the behavior doesn't
> change if the dependencies were not applied before, I have no objections.

Good.
Note that there is some discussion on github too, but not really about 
the above points.  See
https://github.com/zopefoundation/Products.GenericSetup/pull/16

>> Less tricky is the second change:
>>
>> Be more forgiving when dealing with profile ids with or without profile-
>> at the start. All functions that accept a profile id argument and only
>> work when the id does not have this string at the start, will now strip
>> it off if it is there. For example, getLastVersionForProfile will give
>> the same answer whether you ask it for the version of profile id foo or
>> profile-foo.
>
> This doesn't make things clearer to me. IIRC the prefixes were added to
> have separate namespaces and an easy way to figure out which kind of
> profile we are dealing with.
>
> Do you propose to make these namespaces obsolete in the code? Or only in
> some places? How do I know if the profile_id argument requires the
> prefix in a specific method?

Basically I want to avoid that GenericSetup says "No, there is no 
profile with id X" and silently thinks "You should have asked me for 
profile-X instead, I have got that one lying around here just fine."

The 'profile-' and 'snapshot-' prefixes are still used.  Most methods 
only cared about 'profile-', but some of those expected the stripped id 
and others the id with the prefix.  I found that frustrating to deal with.

Some methods handle both 'normal' profiles and snapshots.  With my 
changes, these now have:
- if profile starts with 'snapshot-': do A.
- elif profile starts with 'profile-': do B.
- else: same as 'profile-'

Is that clearer?


-- 
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl