Maurits van Rees wrote:
> 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.
in the beginning there were just base profiles. I added the concept of
extension profiles 10 years ago. Someone else added upgrade steps later.
Extension profiles were added to allow splitting up profiles in
different parts that are shipped with different products. Nobody ever
thought about how this should work with different profile versions and
> 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.
The Import tab wasn't built with extension profiles and upgrade steps in
mind. It is not exactly the UI you expect for installing add-ons.
One issue you want to fix is this:
Someone installs an add-on on a site that has outdated configuration.
Because nobody warns him, he messes up the configuration of his site.
Your answer is: Don't bother him with this detail, I'm sure he wanted to
upgrade his dependencies first. I'll do that for him silently.
My answer is: His site is in a bad state if he didn't run the upgrades.
He should fix that before he starts installing add-ons.
> 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?
In other words: 'profile-' is the default prefix. All methods handle ids
without prefix the same way as ids with the default prefix. Correct?
Zope-CMF maillist - Zope-CMF@zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests