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?
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
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.
> 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
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?
Zope-CMF maillist - Zope-CMF@zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests