Plugin documentation still claims plugins can only be written in C++

[michel-slm]

The documentation for DNF5 plugins https://dnf5.readthedocs.io/en/stable/tutorial/plugins/index.html claims that they can only be written in C++

Could this be edited to document the ability to write Python plugins now? (and whichever other language is supported)

https://github.com/rpm-software-management/dnf5/blob/main/libdnf5-plugins/python_plugins_loader/plugin.py

[jrohel]

The dnf5 project supports two types of plugins.

DNF5 plugins:
These are plugins for the dnf5 application and allow to extend it with new commands.
DNF5 plugins can be written in C++. Currently there is no support for other languages.

LIBDNF5 plugins:
These are plugins for the libdnf5 library. The libdnf5 library provides hooks on which plugins can be hung.
libdnf5 plugins can be written in C++.

1. However, it is supported for the plugin to register additional plugins. It is possible to write a plugin that will load plugins written in another language and register them. When I did the basic plugin architecture 4 years ago [dnf5] Plugins architecture for libdnf libdnf#1134, I wrote a prototype plugin python_plugins_loader that loads plugins written in Python. However, this plugin was not developed further.

2. I also created an actions plugin. The action plugin allows individual hooks to trigger external processes (executables). These processes can be written in any language and can interact with the libdnf5 library. I have recently extended the communication capabilities between the libdnf5 library and the processes Birectional communication of libdnf5 actions plugin with running processes - "json" mode #1642. The documentation of the communication protocol is not yet written. However, an example of communication can be seen in the unit tests libdnf5 plugin actions: Tests for JSON communication mode ci-dnf-stack#1544.

I want to extend the documentation of the actions plugin to include the communication protocol, and look at the state of the python_plugins_loader plugin. When, depends on time and priorities.

Notes:
Personally, I don't like plugins in other languages. Yes, it is a nice benefit for plugin creators. However, one of the advantages of dnf5 over dnf4 is that it doesn't depend on Python. It is smaller and can be used as a replacement for microdnf. Using plugins written in Python eliminates this advantage of dnf5. This is one of the reasons why I implemented libdnf5 Python plugin support using a plugin. Thus, the libdnf5 library itself is not dependent on Python.

In case of the need to write a plugin in another language, it is worth considering whether the actions plugin mentioned above could be used. External programs can be written in any language. Unlike plugins, they run as a separate process. While starting a process has a negative impact on performance, running a plugin as a separate process can be an advantage from a security perspective. For example, a process can run with different permissions than libdnf5. Of course, it is still true that if an external program will require Python (or anything else), using it implies having the necessary dependencies on the system.