Rob Miller wrote:
> hi all,
> i've got a GenericSetup branch called 'ra-depends-tag' with a working
> implementation of a <genericsetup:upgradeDepends> ZCML tag. this tag
> can be used anywhere that you could use a <genericsetup:upgradeStep> tag
> (i.e. either standalone, or nested within a
> <genericsetup:upgradeSteps>). in fact, upgradeDepends is simply a
> special case of upgradeStep that allows you to specify a set of profile
> import steps to be re-applied to the site, rather than calling a generic
> python handler.
> here's an example of how it looks:
> title="Re-run 'foo' import step"
> or alternatively:
> title="Re-run 'foo' and 'bar' import steps"
> import_steps="foo bar"
> title="Do something else"
> some notes:
> - there is no problem nesting both upgradeStep and upgradeDepends tags
> within the same upgradeSteps tag
> - the purge and run_deps attributes are optional and both default to False
> - the import_steps attribute is of token type, so you can list multiple
> steps separated by whitespace and they will all be run
> - the import_steps attribute is optional, if it is omitted then the
> entire profile will be reapplied
> - it's not demonstrated in the examples above, but the 'checker'
> attribute (which points to a callable that can be run to determine
> whether or not the upgrade action should be performed) is supported, it
> functions exactly as it does within an upgradeStep tag
> the justification for the existence of this tag should be pretty
> obvious. one of the most frequent actions that need to be performed
> when upgrading to a new version of a product is the reapplication of
> whichever import steps have been modified since the last profile
> revision. you could use the upgradeStep tag to point to a handler that
> performs this operation, but that requires boilerplate python code, and
> there's no easy way to express whether or not you want the dependencies
> to be run, or purge_old to be set, or even which steps should be run.
> this tag resolves those issues.
> please feel free to peek at the branch and provide feedback on the
> work. if there are no objections, i'd like to merge this to the GS
> trunk as soon as it is deemed appropriate by the release manager.
can i assume from the silence that there are no objections to me merging this
to trunk? if i don't hear any within the next 24 hours or so, i'll go ahead
and do so.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests