[Zope-CMF] Multiple GS profiles per product

[Maurits van Rees]

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]