Module upgrades for output modules

[remram44]

It probably make sense to upgrade from *Cell modules to *Output modules.

• matplotlib: MplFigureCell->MplFigureOutput
  • v2.1: 1.0.1, master: 1.0.4
  • 1.0.2: fixes to plots, 1.0.3: dont-use-modules-as-data, 1.0.4: added MplFigureToFile
  • will use 1.0.5
• tabledata: TableCell->TableOutput
  • same version 0.1.5 because of backport (3d324de)
  • should bump to 0.1.6 after backport and will use that
• vtk: VTKCell->vtkRendererOutput
  • v2.1: 0.9.4, master: 0.9.5, New version of the vtk package #998: 1.0.0
  • 0.9.5: dont-use-modules-as-data
  • will use 0.9.6 or 1.0.0
  • "save camera" feature?
• spreadsheet: RichTextCell->RichTextOutput
• ImageViewerCell->ImageOutput (Implements ImageOutput and fixes output mode priorities #1013)
  • v2.1: 0.9.2, master: 0.9.3
  • 0.9.3: dont-use-modules-as-data
  • will use 0.9.4
• keep *Cell module if some ports are connected/set

[dakoop]

Yes. This was not done originally as *Ouput had not received enough testing.

[remram44]

I just rebased this (across VTK package merge, #998); I'm running into issues with upgrades also. It looks that if I have upgrades for some modules from x to 1.0.0, and package version is 1.0.1, the upgrade fails. I think a call to attempt_automatic_upgrade() is missing somewhere, cc @dakoop.

[rexissimus]

I had the same problem for VTK. Upgraded modules needed to have an upgrade path to the final version. Adding an attempt_automatic_upgrade() call somewhere can hopefully fix this.

[remram44]

The problem here, compared to the database migration systems I'm used to, is that:

• Upgrades are performed for each module, taken independently, rather than upgrading package versions in lockstep;
• We do not have the "schema" for intermediate versions (or even the list of versions).

A lot could be inferred from the provided upgrades, but it's not easy.

I think what you ran into is different and is an actual bug.

[remram44]

Should now be fixed, but that makes the upgrades very awkward.

[dakoop]

So the problem is that the automatic upgrade is not performed after an earlier (non-automatic) upgrade is performed? For example, if you wish to upgrade from 2.0.0 to 2.1.1 and a 2.0.0 -> 2.1.0 upgrade is an explicitly defined upgrade, but 2.1.0 -> 2.1.1 would assume an automatic upgrade, that second upgrade does not happen? Yes, this should be fixed in the general upgrade logic.