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

[Florent Guillaume]

Regarding CMFQuickInstaller, I wanted to remind the list that CPS has 
subclassed portal_setup to add a number of functionalities related to 
upgrades (but not really uninstall): <cps:upgradeStep>.

I also revamped part of the ZMI to provide easier ways to apply one 
import step for one profile (in non-purge mode).

People are welcome to take that code and fold it back into CMF.
(I'm very pressed by internal project at the moment so won't do it myself.)

Installing a CPS 3.4.1 site to check the features out wouldn't take you 
much time :)

Florent


yuppie wrote:
> GenericSetup uses a completely different approach than 
> CMFQuickInstaller. It is focused on states, not on changes.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
> 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.
> 
> - 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.
> 
> - 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.
> 
> - 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.
> 
> - 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.
> 
> 
> Cheers,
> 
>     Yuppie
> 
> _______________________________________________
> Zope-CMF maillist  -  Zope-CMF-lEa0QfImRKZ5o+NzvwT5Tw at public.gmane.org
> http://mail.zope.org/mailman/listinfo/zope-cmf
> 
> See http://collector.zope.org/CMF for bug reports and feature requests
> 


-- 
Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com