Skip to content

Better setup mechanism

Sunil Mohan Adapa requested to merge SunilMohanAdapa:better-setup into master

Created by: SunilMohanAdapa

The actual set of changes are small and easy. Each application required updates and I made those changes make the number of lines modified large. I tried to make all of those changes separately for easy review.

As side-effect of the implementation, I see much faster page loads due to elimination of package installation and also ability to perform queued installations and parallel setups.

Most of the intended changes are completed but very small parts remain. Here are my design notes they may be useful.

Design notes

Usability

  • DONE Applications should be visible without getting setup. Description should be visible before setup. Plinth should provide a generic mechanism for starting setup.
  • DONE Must be very simple for applications to write setup mechanisms. Setup process should have a synchronous flow if possible. Plinth should automatically show a progress of the setups happening.
  • DONE Ability to run --setup during first install to setup critical packages. This should be synchronous and should not start a server.
  • TODO Ability to upgrades applications during Plinth upgrade. Package manager will be running during Plinth upgrade. Plinth will be restarted, during upgrades. Initially this may be implemented by users having to manually run the setup process again. Later a background process which waits for package manager to finish can automatically trigger upgrades.
  • DONE Ability for application to specify that they are critical for operation of Plinth and must be installed by default.

Design for Application:

  • DONE Applications will specify a version number (simple integer) in their init module. This will be incremented whenever the application intends to upgrade an existin setup.
  • DONE Application will implement setup(), they will call utility methods to run a pre-setup operation, install packages and post-install operation.
  • DONE Application setup process shall be idempotent.
  • DONE Application setup process will receive the older version as arguments. This may be used to perform upgrades instead of fresh setup. Older version will be NULL for first time setup.
  • DONE Application will have a flag to indicate that it is critical for the functionality of Plinth. This application will be setup initially.

Design for Plinth:

  • DONE Currently setup version numbers of applications will be stored by Plinth and will be compared with current module version numbers to see if an application needs upgrading.
  • DONE Using a middleware, Plinth will intercept all module views and check if the module requires setup or upgrades. It will prompt and show progress accordingly instead of allowing the view to be shown.
  • DONE Plinth will implement a '--setup' command line which will upgrade all applications and install critical ones.
  • TODO Plinth setup process will proceed in the dependency order. If a setup for an application fails, it's dependencies will not be setup.
  • DONE Show errors during installation properly
  • DONE Handle empty setup
  • DONE Remove old style package views and decorators

Merge request reports