[Zope-CMF] Re: [dev] RFC: rethinking GenericSetup extension profiles
Hi Tres! Tres Seaver wrote: yuppie wrote: So the use cases for these DeltaProfiles are very limited. Using XSLT would allow us to unify DeltaProfiles and ExtensionProfiles, providing an automated way for creating ExtensionProfiles. The major use case for deltas (no matter whether they do XSLT transforms or apply patches) is to permit re-applying local changes after an upgrade. They aren't likely to be satisfactory as a mode for distributing add-ons, I think. I agree that creating ExtensionProfiles for add-ons will never be a completely automated process. But it would be easier to polish a generated profile than writing ExtensionProfiles from scratch. More important is that ExtensionProfiles can be applied to a profile, not just to a site. If that is not the case your use case (re-applying local changes after an upgrade) will not work. I hope this example illustrates the problem: Step 1: A Site is created using a base profile and some extensions. Step 2: The site is customized TTW. Step 3: An additional ExtensionProfile is applied. Step 4: The site is further customized TTW. Step 5: Now we want to upgrade the used profiles. How would you create the necessary DeltaProfile? AFAICS this only works if we are able to create an uncustomized version of the profile combination used in that site. At no point you can create this uncustomized profile with a snapshot. And right now the only tool we have for combing profiles is the site itself. So we either have to implement a machinery that allows to apply the existing ExtensionProfile format to base profiles directly or we have to switch to a new format for ExtensionProfiles. That new format should use a generic format like XSLT or diff. Diffs are not made for manual editing and break easily if the base profiles are changed / updated. I would definitely like to break the requirement that extensions have to displace (even temporarily) the tool's import profile. I would also like to work out how we might safely revert the application of an extension, as well as tracking dependencies among them. I am *not* sanguine about using XSLT as the primary mechanism for describing an extension. While I still believe XSLT would be the most powerful solution it is not a necessary part of my plan. My initial posting described an alternative approach: If we split up the profile files in small pieces we can use layers and just override the pieces we want to change. This is not as fine grained as diffs or XSLT, but in exchange much simpler. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] RFC: rethinking GenericSetup extension profiles
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 - [EMAIL PROTECTED] 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 RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Abusing GenericSetup during traditional installs
Rob Miller wrote: maybe i'm missing something, but is there a reason why you wouldn't want to simply make your profile active and then import specific steps programmatically from within your install method, rather than invoking the import adapters manually? Because in this case I wouldn't want to use extension profiles. :) Basically, the use case would be that (a) I hate doing workflows by python, but (b) I need to have a traditional quickinstaller-installable product. That is, one that can be easily uninstalled and one which is made available in Plone's Add/Remove Products configlet. Thus, I was hoping to be able to re-use the syntax and import logic from GS without using the actual profile mechanism. I took a look at the tests yuppie suggested, but I'm a bit lost still - there's a lot of base classes and roundabouts there, and I get confused about the level of abstraction I'm looking at - XML bodies and elements, properties and objects. I had to put it on ice whilst doing other things for a while, but I'd like to revisit as soon as I can. If anyone has a more complete and concise code example for this use case, please let me know. Martin ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
