Possible implementation for reporter/output handlers #13897
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This pull request demonstrates not only how reporter and output handlers are defined as plugin hooks within conda but also gives a practical example of their usage in the
conda info
command. Along with the code changes itself, below is an explanation of this API and how it will be used in conda.ReporterManager
APIWhen interacting with this API, most conda contributors will be using an instance of the
ReporterManager
class. This class is a singleton and is therefore accessed via theget_reporter_manager
function to ensure we only create one object per program run.The
ReporterManager
class has arender
method which accepts a heterogeneous object that will eventually be converted to a string and rendered to one of the configured output handlers (e.g.stdout
). Optionally, callers can specify acomponent
that will use a custom rendering function defined by the reporter handler. Currently available rendering functions only include "detail_view" and "envs_list", but this will be expanded as continue to incorporate this into more areas of the code.Because the "component" argument is optional, the default behavior of the render method will be to either try to convert the object to a string and pass it to the registered output handler, or if it is the JSON reporter handler, it will attempt to render the object as a JSON string and pass it to the registered output handler.
Below is an example of how this looks in practice:
By itself, the above example doesn't look impressive at all and perhaps a little cumbersome. The real power of this approach is now we are able to configure any number of reporter/output handler pairings. This means that when we want to change the output to JSON we do not have to change any of the code above.
A note about the
conda info
refactorWhile digging into the refactor of
conda info
, I discovered a couple quirks with the existing code. I was hoping to remove most logic that relied on directly checkingcontext.json
, but that simply wasn't possible considering how it worked. This will most likely still be present in most of our code as we proceed with the refactor because what the "console" output displays isn't always a direct mapping to what the "json" output displays.Inside the
conda.cli.main_info
module, I have also intentionally left a piece of the output rendering in the module itself rather than porting it toconda.plugins.reporter_handlers.console
like I did forenvs_list
. This is in part to show it is possible to still do the layout handling in the module itself, but if I were to completely refactor that module, I would favor moving that logic to theconda.plugins.reporter_handlers.console
and simply make it available as a type of component we could use.