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 Seaver          +1 540-429-0999          [EMAIL PROTECTED]
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to