Aha - so it seems was confused :) So, to be clear, "run all import steps"
will only apply to the last selected "active" profile, even if that's an
Yes. The ImportContext has only access to the last profile selected.
What still might happen with broken import handlers - especially
importVarious - is that the handlers themselves change settings
independent of any profile files.
Aha. What's the correct pattern to use in an importVarious in order not
to have that problem (bearing in mind I'll probably be documenting this
as part of a tutorial soon, I figure I'd get the story straight... :-)
Thanks for the update. So long as we keep the "trying out a new
case in mind and focus on making it as easy to make import handlers, I
we're very much on the same page.
Fine. But the fact I started this thread doesn't mean I have the
resources to write a detailed proposal and implement it. So the big
question is: Who will contribute the necessary resources and do the job?
My knowledge of GS and time to learn it are both in short supply - there
are Plone deadlines coming up, among other things. :-/
I'm happy to help with testing, use cases and documentation, though. Do
you have an idea of the scale and complexity of your proposal?
By the way - two other things I brought up in the post to plone-dev was:
- We need some way of exposing to the user the *version* of the profile
being applied, i.e. the version of the product. "You have Foo version 1.0
installed, but version 2.0 on the filesystem. Do you want to upgrade?"
- We need some way of expressing dependencies between profiles, so that
installing Foo also installs Bar. It should be possible to do optional
dependencies, too, so that Foo installs Bar if Bar is available, but
fail if it's not.
Agreed. We might even need a combination of both: E.g. Foo depends on
version 1.0 of Bar. See also this short thread:
Good point :)
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests