Support CLI installation for the plugin

[reiferschris]

Is your feature request related to a problem? Please describe.
I want to set up reproducible dev/test environments preferably based on container images. The plugin however to my knowledge needs to be installed and then updated via the UI. Then you need to load an existing configuration.

Describe the solution you'd like
Have a way to fully setup ILIAS with the plugin installed, activated and configured from the CLI

Describe alternatives you've considered
hacking my way to that goal with curl and sql

Additional context
I can't find any documentation on what the ilias /setup/cli.php expects to successfully install a plugin

Can someone point me in the right direction? Has anyone attempted this before (maybe with another plugin)?

[dagraf]

@chfsx In the last community meeting (in July) you offered to add more information about your/the plans concerning this issue. Could you add those informations before our next meeting tomorrow? This would be great.

[chfsx]

The refactoring work in PR #186 is a further step so that we can later safely support CLI installation and CLI update. However, more such work is needed. Specifically, we need to remove all the following libraries:

• srag/custominputguis
• srag/datatable
• srag/dic
• srag/librariesnamespacechanger

see https://github.com/opencast-ilias/OpenCast/blob/main/composer.json#L26.

In PR #186 we could already remove all uses of srag/dic, which is the biggest refactoring so far. However, the library is also used internally by the other two libraries srag/datatable and srag/custominputguis, so we have not yet been able to remove it completely.

Once the libraries are completely removed, we can start testing the CLI installation and the CLI update. But what is still an open point (in my opinion) is that after the installation you still have to configure the plugin first to be able to use it. If the plugin is to be delivered with a default configuration, we would have to take a closer look at the import/export mechanism in the plugin configuration. The whole configuration should be refactored so that it can be exported and imported very easily and that especially with new settings these are always exported directly (and not forgotten in the export/import, which was probably often the case in the past). Then we could provide a demo confguration and deliver with the plugin, this would then be imported during the initial installation.

But we are talking about a major refactoring here as well.