yuppie-2 wrote:
GenericSetup uses a completely different approach than
CMFQuickInstaller. It is focused on states, not on changes.
Indeed. From having used it recently, it just seems to be an easier way of
working, so I'm trying to find out how we can meet the use cases that CMFQI
meets now based on this technology - if at all.
The early versions of GenericSetup (FKA CMFSetup) didn't even have
extension profiles and importVarious handlers. I invented those hacks to
give GenericSetup more momentum, but especially importVarious was never
meant as a permanent solution. The GenericSetup UI is counter-intuitive
because it was built for complete profiles/snapshots. importVarious is
dangerous because it is a hack.
That was my feeling too. I can see that it will be a necessary hack, though,
until we've covered everyhing anyone ever wanted to do with some
import/export handler.
I know that so far GenericSetup can't replace CMFQuickInstaller. But the
fact people are missing CMFQuickInstaller functionality doesn't mean it
has to be implemented following the old patterns.
/quiote
No, definitely. What I was trying to get back to was the original use cases
for CMFQI - people download some product, want to try it out, install it,
decide they don't like it, uninstall it, or re-install it for an upgrade, or
leave it in place.
Incidentally, one of the biggest problem peoplems people have with Plone is
that they configure a site a certain way (including third party products)
and then want to deploy that to a production server, leaving content intact.
GS is obviously the answer to that, so I'm keen on trying to promote third
party products that integrate with it as well as possible.
Install/uninstall code for CMFQuickInstaller is hard to write, usually
only add-on programmers do that. Just replacing python code by XML-files
will not make it much easier.
But 90% of what we do in an installer is boilerplate - add a workflow,
register a new content type, install a skin - all stuff that's done easier
with GS than with python APIs.
And now regarding your concerns:
- I don't think we should use the same machinery for configuration data
and content. (I know the distinction is fuzzy, but the big mass is pure
content.) AFAICS it is not very hard to specify areas that contain
content and should not be touched if profiles are reapplied.
+1
- The procedure I have in mind depends on the ability to create
customization snapshots. As a first step the setup tool would create
this snapshot. In the next step it would combine all dependencies of
that snapshot minus uninstalled extensions plus new extensions. The
result is a profile that contains the latest data of all selected
profiles plus the customizations from the snapshot. This profile would
be used to reset the site.
Bearing in mind that my understanding is not completely solid, the option I
keep thinking we need is to say run all import steps, but only for this one
extension profile. I have a workflows.xml and a types.xml and whatever else
in my extension profile for my product. I'd like to uninstall or re-install
or install workflows and types *for my product*, but I'm not interested in
evaluating every workflows.xml and types.xml in every active profile
everywhere (e.g. those that came with Plone or CMF or some other product),
lest they'd changed or I'd changed them and didn't want my changes stomped
on. Even though the actual import step is defined in another product (e.g.
CMFCore) I assume it'd be possible to simply not include steps for other
profiles?
- Speed is not that important. It doesn't hurt if it takes a few seconds
until a profile is installed or uninstalled. There are a few very
expensive tasks like creating indexes. The handler can make sure indexes
are not removed if the new profile needs the same index.
Probably true. On plone.org we've had cases where things result in reindexes
that take 45 minutes or more to reindex, causing Squid timeouts and other
nastiness. We just to be a bit careful, I guess.
- I don't know if we really need a way to reset specific products.
AFAICT the more common use case is to reset specific objects like tools.
I'd prefer a tab on the object that allows to load preconfigured
settings instead of using the setup tool for that.
This doesn't resonate with my experience from Plone, if I'm understanding
you correctly. I agree that some way of resetting individual tools may be
useful, but that's still very low level. If Joe Average downloads
CMFCrazyPollingProduct, he may install it, and need to un-install it
cleanly. He may also need to re-set it if he messed up its configuration or
maybe he's the developer and wants to test the effects of a clean
re-install. Or, if the product is updated, he may need to re-run its
installation.
- While I hope we can get rid of importVarious it would be less
dangerous to use if only complete profiles are
