-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Maurits van Rees wrote:
> 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. Sees reasonable, although I should say that I don't use the "upgrade" machinery in GS at all. > 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. This is a bug: QI should probably be displaying *all* extension profiles registered for the site root interface, rather than trying to bless one per product. > 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. Proposed changes to QI aren't exactly in scope on this list. > 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. Yes, I use multiple profiles. > Question 3: Should we encourage programmers to only use one profile, > presumably simply in a directory named 'profile' by default? No. The name 'default' should *definitely* not be majyk. > 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. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFILcXV+gerLs4ltQ4RAjNCAJwOucCo9ReYq3IzCufEy66tHR6q+gCgz7zI Fa1hgTbGR1rN99/F4HRCUfk= =Q0j0 -----END PGP SIGNATURE----- _______________________________________________ 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
