Possible implementation for reporter/output handlers

[travishathaway]

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 API

When 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 the get_reporter_manager function to ensure we only create one object per program run.

The ReporterManager class has a render 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 a component 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:

from conda.common.io import get_reporter_manager

reporter_manager = get_reporter_manager()

# prints a simple string
reporter_manager.render("hello")

# output:
# hello 

# prints a detailed view
data = {"field_one": "value_one", "field_two": "value_two"}

reporter_manager.render(data, component="detail_view")

# output:
# 
# field_one : value_one
# field_two : value_two
# 

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 refactor

While 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 checking context.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 to conda.plugins.reporter_handlers.console like I did for envs_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 the conda.plugins.reporter_handlers.console and simply make it available as a type of component we could use.

[codspeed-hq]

CodSpeed Performance Report

Merging #13897 will not alter performance

_{Comparing travishathaway:reporter-output-experiment (c97e71f) with feature/reporters-backends (6ce69e9)}

Summary

✅ 21 untouched benchmarks