A story about QuickInstaller and GenericSetup cooperation

Hi,

So, I have been having some fun with the CMFQuickInstallerTool (QI)
and GenericSetup (GS) and how they cooperate.  It's quite interesting,
really.  Sit back and relax.

Mostly this is about applying a GS profile and marking the corresponding 
product as installed in the QI.  And then uninstalling or unmarking.

Some version numbers:

- QI 2.0.4 (introduced in Plone 3.0.4 or 3.0.5) starts using
   GenericSetup events: if a GS profile is applied, mark its
   corresponding product as installed in QI: generate an
   InstalledProduct instance, including a list of which skins etc were
   added during the install.

- QI 3.0 (Plone 4.0) optimizes this logic by ignoring any
   non-installable profiles.  These are profiles listed in a utility
   that implements Products.CMFPlone.interfaces.INonInstallable, with
   as goal to make some lists of profiles in the UI shorter and more
   comprehensible.  Do not confuse this with
   Products.CMFQuickInstallerTool.interfaces.INonInstallable, which is
   about products.

- QI 3.0.7 (Plone 4.3.4 / 5.0a3) removes the InstalledProduct instance
   when a product is uninstalled, because leaving the instance around
   can prevent settings from being stored properly on subsequent
   installation of the product.

- QI 3.0.8 (Plone 4.3.5 / 5.0b1) no longer prevents INonInstallable
   profiles from being recorded as QI installed products, because
   really they are auto-installed products, not non-installable ones.

BTW, are you looking for a script to download all versions.cfg files
from dist.plone.org/release so you can easily grep through them to see
which version of a package is used in which Plone version?  See
https://gist.github.com/mauritsvanrees/99cb4a25b622479e7dc3

With this in mind, how do you check whether a profile or product has
been installed?  For example, in plone.app.upgrade you may want to
decide whether or not to run an upgrade step for plone.app.collection.
You cannot always say 'this is Plone 4.2, so plone.app.collection is
sure to be installed,' because an upgrade from 4.1 to 4.2 does not
actually install this package.  So you have to do some checks if you
want to know this.

For simplicity we only consider a product with one profile
(``default``) and no External installation method.  There are several
ways to check its installed status:

1. Check the installed profile version in GS::

      if portal_setup.getLastVersionForProfile('my.package:default') != 
'unknown':
          # package is installed

    But wait: the profile was applied but the product may have been
    uninstalled afterwards.

    TODO: update QI so that uninstalling a product unsets its last
    profile version in GS.

2. Instead, check the product in QI::

      if 'my.package' in QI:
          # product is installed

    But wait: this may find an outdated InstalledProduct instance for a
    product that is no longer installed.

    TODO: update code that uses this pattern to the next pattern.
    plone.app.upgrade uses it.

3. Instead, check the status in QI::

      QI.isProductInstalled('my.package')

    But wait.  If this is a profile that was listed as INonInstallable
    and was applied between QI 3.0 and 3.0.8, it will not have been
    marked as installed in the QI.

    TODO: write an upgrade step in plone.app.upgrade to go through all
    INonInstallable profiles, check if the profile was applied (method
    1) and mark it as installed in QI.  This might mark too many of
    these as installed, but so be it.

    TODO: write an upgrade step in plone.app.upgrade to go through all
    InstalledProduct items in the QI and remove any with getStatus()
    'uninstalled'.  And unset their last profile versions in GS too.

And when you get this all right and conclude that a profile or product
is installed and you want to run its upgrade steps, you should still
first check whether the package is available, because it may be
something like Kupu or TinyMCE that is no longer included in your
Plone version.  Oh, but when the package is not there, there will not
be any upgrade steps registered in zcml, so that should not give a
problem really.  Some luck at last.

Do those TODO items sound sane?
I can see about implementing them.


Somewhat related issue:
   Upgrade Plone 4.1 to 4.3: TinyMCE, CMFEditions and sunburst are not 
upgraded
   https://github.com/plone/Products.CMFPlone/issues/812

Pull request to fix those specific problems:
   4.3: Properly update TinyMCE, CMFEditions, Sunburst
   https://github.com/plone/plone.app.upgrade/pull/42

Pull request to fix the general problem of not updated core packages:
   Upgrade core addons at end of Plone migration
   https://github.com/plone/Products.CMFPlone/pull/823

Note that those pull requests do NOT include the TODO items I mention
above (except TODO number 2 partially).

Comments?

-- 
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl


------------------------------------------------------------------------------