GS Upgraded buildout Plone: versions mismatch in portal_quickinstaller

portal_quickinstaller still seems like a necessary evil tool requiring to view TTW, changes done to the base configuration GS aware packages (manage_installProductsForm).

It provides a view with a list of versioned add-ons in addition to options for installing, uninstalling & reinstalling packages, in comparison to its counterpart prefs_installl_products_form.

Our site has been upgraded from 5.1.2 to 5.1.4, portal_quickinstaller shows the version registered in the database at installed time and the latest version available after the upgrade. For most of the add-ons in the list, packages align well to the version in the file system.

For instance: “Dexterity Content Types” version at install time is 2.5.1 and after the Upgrade the product version is 2.5.1. Thus, matching db and file system.

However, there are other packages showing red in the manage_installProductsForm list and do not match the version after the Upgrade. One example is the package “Mandatory dependencies for a Plone site” => version at install time: 5.1.2.1 after the Upgrade, the product version is: 5.1.4. Thus, showing misleading information.

Questions:

  1. Technically, why are some packages not aligning to the most recent upgraded version?

  2. Since it is misleading, what is the plan to consolidate features from form manage_installProductsForm into prefs_install_products_form?

  3. Displaying a package version in prefs_install_products_form would be nice, if it is enforced, we’ve got a few costumed add-ons not displaying the version in this tool.

Note: In the above concerns, there is no reference to running upgrade steps — as we know that can be done through portal_setup/manage_upgrades.

Old question by now, but it deserves an answer. :slight_smile:

In general: the form you are talking about is the old form from Products.CMFQuickInstallerTool. A future Plone 6 version will not ship with this package anymore. It is currently still installed, and the portal_quickinstaller tool is created, and its information is kept in sync with what is shown in the Plone UI in the prefs_installl_products_form (Extra Products).
See the 5.1 upgrade docs and PLIP 1340 for more information.

Your example "Mandatory dependencies for a Plone site" is the "dependencies" profile of the core CMFPlone package. When you installed it (automatically upon creation of the Plone Site) CMFPlone had version 5.1.2.1. Currently it has a higher version 5.1.4. Theoretically you could select the product and reinstall it (don't do this!) and it would show version 5.1.4 in both columns. But this is not needed (and not advised), because nothing has changed in this product that would require an upgrade or reinstall.

So the quick installer shows correct information, but in this case it is information that you do not need. It is one of the reasons why you should not use the portal_quickinstaller tool anymore.

The plan is to remove manage_installProductsForm and the entire portal_quickinstaller. The core of Plone 5.1 already does not need it, and the Extra Products form does not use it.

This form already should already show the package versions, for example I see in the available add-ons this information about plone.session:

Session refresh support [profile title]
Optional plone.session refresh support [profile description]
(plone.session 3.7.3) [package name and version]

Maybe the version number does not show up if you do not have a proper Python package but an old-style Product.

1 Like

Thorough response @mauritsvanrees :slightly_smiling_face:

The issue is with the practice of using develop = "." in buildout and not versioning the python packages.

Decoupling the packages from buildout is necessary in order to be able to Uninstall them and be able to Install them again -- in addition to being able to use them in other builds without carrying an entire solution.

Thus is better having a properly packaged add-on (egg) and not a tight buildout with glued in addons that cannot be uninstalled.

Plone Foundation Code of Conduct