Hi, Some observations here with a few questions sprinkled through.
For Plone we at Zest Software made eXtremeManagement (affectionately called xm), a project management tool. See http://plone.org/products/extreme-management-tool For upgrading from Plone 2.5 to 3.0 I made an "upgrade profile": basically just a regular extension profile that is not meant to be run directly from the portal_quickinstaller or portal_setup but that is only hooked up to an upgrade step like this: def from_plone25_to_30(context): context.runAllImportStepsFromProfile( 'profile-Products.eXtremeManagement:eXtremeManagement-30-types', purge_old=False) It removes some actions from some portal types, which seemed handy to do in a GS profile instead of manually coding some python. Works fine actually. This is on Plone 3.0 with CMFQuickInstaller 2.0.4. Note that for GS upgrade steps you do not really need "upgrade profiles". That was just my understanding/expectation of how to do upgrade steps at the time. But: along comes Plone 3.1.1 with CMFQuickInstaller 2.1.4. This has slightly different handling of GS profiles. In this case when visiting the portal_quickinstaller in the ZMI it does not seem to care much for the Extensions/Install.py, it finds the two profiles (the "upgrade" profile and the default profile) and picks the first one it finds and print its name in the list of installed/installable products. So the QI now gives eXtremeManagement the dopey title of "eXtremeManagement types fix for Plone 3.0", which is the title of the upgrade profile. Question 1: can I influence which profile is picked here? Should we add some code to the QuickInstaller.getInstallProfile(s) methods to for instance prefer a profile with a name like "productname:default"? For reference, this is info from the two profiles I now have: [{'description': u'eXtremeManagement types actions fix for Plone 3.0.', 'for': <InterfaceClass Products.CMFPlone.interfaces.siteroot.IPloneSiteRoot>, 'id': u'Products.eXtremeManagement:eXtremeManagement-30-types', 'path': u'/home/maurits/buildout/test/products/eXtremeManagement/profiles/30', 'product': 'Products.eXtremeManagement', 'title': u'eXtremeManagement types fix for Plone 3.0', 'type': 2, 'version': '1.5.2'}, {'description': 'Profile for Extreme Management', 'for': <InterfaceClass Products.CMFPlone.interfaces.siteroot.IPloneSiteRoot>, 'id': 'eXtremeManagement:default', 'path': 'profiles/default', 'product': 'eXtremeManagement', 'title': 'Extreme Management', 'type': 2, 'version': '1.5.2'}] The first one is the upgrade profile, only meant to be used via the Upgrades tab in portal_setup. The second one is the default profile that I want to have available in the quick installer. Now, I tested with eXtremeManagement 1.5.2, the latest stable release, in case anyone wants to try it out (remember to add a Poi 1.1 bundle too). That release also has Extensions/(App)Install.py files. I moved those out of the way and restarted. On Plone 3.0 everything seems to go fine: the name in quick installer is 'Extreme Management' and installing it does everything it needs to do, using the default profile. This is because the upgrade profile is not found, due to a slightly different implementation of the getInstallProfile method. Now, on Plone 3.1.1 (QI 2.1.4) with a fresh zodb the QI lists that strange name of the upgrade profile instead of the name of the default profile. And indeed when installing it only that upgrade profile is executed, not the default profile. Question 2: I am used to having a profiles directory in a product and a subdirectory inside it named 'default'. eXtremeManagement is the only product I know that has a second profile next to it. Are others using more than one profile? Well, CMFPlone does a few things here. Question 3: Should we encourage programmers to only use one profile, presumably simply in a directory named 'profile' by default? In the case of eXtremeManagement, the day is saved because it still has an Extensions/Install.py. That is the installer that is actually executed and it has some code to run the correct profile, including a dependency. The only hickup so far is that with the newer QI the name of the other profile is listed instead of the default profile. Meanwhile on trunk (and on the 1.6rc5 I released on the cheese shop last night) I have removed the upgrade profile as I do not like the side effects of having two profiles. Hm, hiding profiles by using Products.CMFQuickInstallerTool.interfaces.INonInstallable could be an option too, now that I think of it. Should work. Reactions are welcome. -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl] _______________________________________________ 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