Robot console plugin system

[InteVleminckx]

I recently made a code contribution to the Robot Framework, which I think will improve usability and flexibility.

I have extended the existing "ConsoleOutput" feature in the Robot Framework to further extend its functionality. This modification allows more easily to select console output types that are determined with the --console argument.

The code that I added discover and load entry points based on the provided group and name. If multiple entries are found, it issues a warning and proceeds with the first discovery. This eliminates the need for manual updates when new/custom output types are added.

I made these changes to the Robot Framework because they provide practical solutions to streamline the selection of console output types. This improvement would help us hard in developing the project we are currently working on. The project is intended to allow users to easily track their test status, but we would also like to be able to easily call the project as a --console option. The modification also has a contribution in the project for other developers using the Robot Framework, provided others also want to pass their own values to the --console argument.

[pekkaklarck]

This sounds like a really useful enhancement, but it needs some more planning.

First of all, we have lot of other APIs that would benefit from a better plugin API and we should plan the plugin system accordingly. We don't need to add all possible plugin APIs now, but the design must be generic. The plugin API would also need documentation and tests.

Secondly, the logging API currently used by console outputs isn't public. We have also lately been changing it as part of logging related changes needed by listener API enhancements. Once it gets stable, making it public shouldn't be an issue. It will basically be the same API as the enhanced listener API v3.

[pekkaklarck]

I just realized I hadn't understood the PR properly. I though the ideas was to be able to just use robot tests.robot and a registered console output would be used. It seems that the idea is to be able to register plugins, but they need to nevertheless be enabled like --console myplugin. That's otherwise a nice approach, but it would be inconsistent with how, for example, listeners and model modifiers are registered. With them you can either use a name of the module (needs to be importable) like ´--listener exampleor an absolute or relative path to a module like--listener example.py`. I believe we should use the same approach also with console outputs. The existing tooling we have for importing modules ought to make that pretty easy.

The above said, a plugin API would be really nice. I believe it should make it possible to automatically enable things a custom console output so that separate command line option wouldn't be needed. That's a lot bigger task than making the console output customizable, though.

[dries007]

(For reference: The Author is a student employee of ours (@Qteal), I'm the Product Owner of the project he's working on.)

So the preference would be to change this mechanism to be in line with the existing listener style arguments (via imports) for now. Would the PR then be acceptable or would the lack of public API still be a problem?
An alternative is that we try to integrate our console improvement project with RF itself, but that will be a harder sell internally, plus you'll end up with the maintenance bourdon 😄.

What is the best channel to engage in a discussions about a plugin API? Because we would love to have a one for everything from listeners to libraries, even if it takes until RF8.0 😄.

Our reasoning for wanting the API is that the current system forces either a lot of unstructured packages (with lots of top level files) or exposing a lot of technical details to users who don't want or need to know them (package structures etc). Also a lot of very long command line arguments and the inevitable associated pile of scripts to cut down on those.