Ok, got it, thank you for your reply.
btw, why is it called stdout_callback? What’s the difference/purpose between stdout_callback and _callback_plugins in TQM?
Alexander.
Per it’s name, it was defined, to only load a single callback that defines itself as ‘stdout’. Generally speaking the name is designed around the idea that the bundled command line tools are the users of the API.
At minimum a “stdout” callback is required.
You can kind of think of it as the “default” callback. All other callbacks are in addition to this default callback.
Ok, thank you. So I’m gonna define all callback methods in _stdout_callback and this way I won’t need any other callback classes. That’s neat =)
Thank you for your replies!
Alexander.
The current thread warns that “only the plugin APIs are guaranteed to work from version to version,” and that the API generally “was not intended for direct use.”
I’ve written an extension to the stdout_callback used in roots/trellis to streamline some output and enable text colors in debug msgs.
However, I have decided not to merge the extension because it calls some Ansible modules in a way probably considered to be outside the plugin API. I figure my particular code poses a moderate risk that future Ansible updates could “break” our project for users. My extension’s features are merely “nice-to-have” and should only be included if the risk is very low.
If anyone cares to look, and thinks my code actually poses little risk, I would love to hear it.
Here is the PR and discussion, the code (see most recent 2 commits), and docs describing relevant features.