[Zope-CMF] [dev] RFC: rethinking GenericSetup extension profiles

[Martin Aspeli]

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 applied to the site.
> 

I suppose, except if I'm trying to just install product X, running some
(potentially destructive) importVarious from some other unrelated product
still seems risky.

Perhaps its FUD, but essentially re-creating a site each time you do an
incremental update (e.g. install a new product) seems really risky to me. A
bad product install can sometimes mess up that product - if you started
getting strange exceptions (and GS exceptions aren't always that easy to
debug, I've found) from somewhere deep within an unrelated product, that
could be pretty scary too.

Martin
-- 
View this message in context: http://www.nabble.com/-dev--RFC%3A-rethinking-GenericSetup-extension-profiles-tf1996759.html#a5484841
Sent from the Zope - CMF list2 forum at Nabble.com.