Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CLI: add verbosity control #5085

Merged
merged 7 commits into from
Aug 24, 2021

Conversation

sphuber
Copy link
Contributor

@sphuber sphuber commented Aug 18, 2021

Supersedes #3896
Fixes #4330

For those reviewing this, I recommend looking at the individual commits.

  1. Simple change to "formally" add the custom REPORT level and the report method to the logging built-in module. This will allow it to be used just like for example logging.DEBUG and logging.debug() and the other standard log levels.
  2. Define a -v/--verbosity option that is automatically added to all verdi commands. When specified on the CLI, this option changes the log level for the AIIDA_LOGGER by setting the corresponding option value on the Profile instance that is loaded in memory
  3. Refactor the echo functions from the aiida.cmdline.utils.echo module to log their messages to the CMDLINE_LOGGER, a direct child of the AIIDA_LOGGER, instead of directly echo'ing the messages to stdout and stderr.
  4. Change majority of echo_info invocations for echo_report. Since REPORT is the default log level, after the previous changes the content of echo_info will no longer show up, so we change them to echo_report.

@codecov
Copy link

codecov bot commented Aug 18, 2021

Codecov Report

Merging #5085 (35fe868) into develop (6023386) will decrease coverage by 0.01%.
The diff coverage is 76.65%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #5085      +/-   ##
===========================================
- Coverage    80.55%   80.55%   -0.00%     
===========================================
  Files          531      532       +1     
  Lines        36970    36999      +29     
===========================================
+ Hits         29776    29799      +23     
- Misses        7194     7200       +6     
Flag Coverage Δ
django 75.24% <76.32%> (+0.01%) ⬆️
sqlalchemy 74.23% <76.32%> (-<0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...site/db/migrations/0032_remove_legacy_workflows.py 61.54% <0.00%> (ø)
aiida/backends/sqlalchemy/manage.py 0.00% <0.00%> (ø)
...s/versions/1b8ed3425af9_remove_legacy_workflows.py 67.17% <0.00%> (ø)
aiida/cmdline/__init__.py 100.00% <ø> (ø)
aiida/cmdline/commands/cmd_calcjob.py 68.80% <0.00%> (ø)
aiida/cmdline/commands/cmd_data/cmd_show.py 16.67% <0.00%> (ø)
aiida/cmdline/commands/cmd_devel.py 27.91% <0.00%> (-2.52%) ⬇️
aiida/cmdline/commands/cmd_process.py 47.85% <0.00%> (ø)
aiida/cmdline/commands/cmd_setup.py 50.00% <0.00%> (ø)
aiida/cmdline/params/options/__init__.py 100.00% <ø> (ø)
... and 37 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6023386...35fe868. Read the comment docs.

@sphuber sphuber force-pushed the fix/4330/cli-verbosity-control branch from e1565f3 to 01030f5 Compare August 18, 2021 08:14
@ltalirz
Copy link
Member

ltalirz commented Aug 19, 2021

thanks a lot @sphuber - I guess you're looking for a review from one of us three.
I'm currently a bit short of time; @ramirezfranciscof would you perhaps be available for this one?

@sphuber
Copy link
Contributor Author

sphuber commented Aug 19, 2021

Thanks @ltalirz . I pinged you since you have wrote the original PR and were involved in all the discussions, but I guess if the other's review it, that would be fine as well. You can always just give feedback on the higher level design and naming decisions and leave the review of the implementation to the rest.

To see what it would look like and how it would work for the user, you can maybe have a quick look at the section I wrote for the docs:

Verbosity
=========
All ``verdi`` commands have the ``-v/--verbosity`` option, which allows to control the verbosity of the output that is printed by the command.
The option takes a value that is known as the log level and all messages that are emitted with an inferior log level will be suppressed.
The valid values in order of increasing log level are: `NOTSET`, `DEBUG`, `INFO`, `REPORT`, `WARNING`, `ERROR` and `CRITICAL`.
For example, if the log level is set to ``ERROR``, only messages with the ``ERROR`` and ``CRITICAL`` level will be shown.
The choice for these log level values comes directly from `Python's built-in logging module <https://docs.python.org/3/library/logging.html>`_.
The ``REPORT`` level is a log level that is defined and added by AiiDA that sits between the ``INFO`` and ``WARNING`` level, and is the default log level.

The verbosity option is case-insensitive, i.e., ``--verbosity debug`` and ``--verbosity DEBUG`` are identical.
The option can be passed at any subcommand level, for example:

.. code:: console

    verdi process list --verbosity debug

is identical to

.. code:: console

    verdi --verbosity debug process list

When the option is specified multiple times, only the last value will be considered.
The default value for the logging level can be changed permanently through the configuration system.
For example, to set the default log level to ``WARNING``,

.. code:: console

    verdi config set logging.aiida_loglevel WARNING

This is identical to passing ``--verbosity WARNING`` manually to each invoked command.

.. warning:: Setting the configuration option does not just affect the verbosity of the command line, but the logging for all of AiiDA.
    For example, it also affects the verbosity of process reports, such as those of work chains.
    If the log level is set above ``REPORT``, the reports of work chains will no longer be logged.

@chrisjsewell
Copy link
Member

Thanks @sphuber.
Initial feedback, I note that you have not removed/replaced the VERBOSE, which I imagine may mean weird behaviour for these commands:

aiida/backends/sqlalchemy/manage.py:
  54: @options.VERBOSE()
  62: @options.VERBOSE()

aiida/cmdline/commands/cmd_code.py:
  147: @options.VERBOSE()
  185: @options.VERBOSE()

aiida/cmdline/commands/cmd_database.py:
  200: @options.VERBOSE()

aiida/cmdline/commands/cmd_devel.py:
  24: @options.VERBOSE()

aiida/cmdline/commands/cmd_group.py:
  96: @options.VERBOSE()

aiida/cmdline/commands/cmd_node.py:
  283: @options.VERBOSE()

one of these is verdi node delete, which I know directly sets the level of the DELETE_LOGGER, which is used in the delete_nodes function. I guess this would need to be changed and also all uses of DELETE_LOGGER.info -> DELETE_LOGGER.report

then there are three instances of directly creating an option with --verbosity, all in the archive:

aiida/cmdline/commands/cmd_archive.py:
   87:     '--verbosity',
  206:     '--verbosity',
  247:             'failed to migrate the archive file (use `--verbosity DEBUG` to see traceback): '
  318:     '--verbosity',

again they directly set certain logger levels, which are then used in the calling functions, plus there is the relationship between verbosity levels and progress bars, which would need to be adapted a bit

@chrisjsewell
Copy link
Member

There are 66 instances of .info( and we should probably decide if these are now better as .report(:

66 results - 17 files

aiida/engine/runners.py:
  328:         LOGGER.info('adding subscriber for broadcasts of %d', pk)
  349:             LOGGER.info('%s<%d> confirmed to be terminated by backup polling mechanism', *args)

aiida/engine/daemon/runner.py:
  28:     LOGGER.info('Received signal to shut down the daemon runner')
  37:     LOGGER.info('Daemon runner stopped')
  58:         LOGGER.info('Starting a daemon runner')
  61:         LOGGER.info('Received a SystemError: %s', exception)
  64:     LOGGER.info('Daemon runner started')

aiida/engine/processes/process.py:
  292:         self.node.logger.info(f'Loaded process<{self.node.pk}> from saved state')
  300:         self.node.logger.info(f'Request to kill Process<{self.node.pk}>')
  311:                     self.logger.info('no controller available to kill child<%s>', child.pk)
  319:                     self.logger.info('no connection available to kill child<%s>', child.pk)
  321:                     self.logger.info('kill signal was unable to reach child<%s>', child.pk)

aiida/engine/processes/calcjobs/calcjob.py:
  421:             self.logger.info('could not parse scheduler output: the `detailed_job_info` attribute is missing')
  423:             self.logger.info('could not parse scheduler output: return value of `detailed_job_info` is non-zero')
  445:             self.logger.info(f'`{scheduler.__class__.__name__}` does not implement scheduler output parsing')

aiida/engine/processes/calcjobs/manager.py:
   97:             self.logger.info('waiting for transport')
  114:             self.logger.info(f'AuthInfo<{self._authinfo.pk}>: successfully retrieved status of active jobs')

aiida/engine/processes/calcjobs/tasks.py:
   95:         logger.info(f'scheduled request to upload CalcJob<{node.pk}>')
  108:         logger.info(f'uploading CalcJob<{node.pk}> successful')
  143:         logger.info(f'scheduled request to submit CalcJob<{node.pk}>')
  154:         logger.info(f'submitting CalcJob<{node.pk}> successful')
  204:         logger.info(f'scheduled request to update CalcJob<{node.pk}>')
  215:         logger.info(f'updating CalcJob<{node.pk}> successful')
  266:                 logger.info(f'detailed job info not available for scheduler of CalcJob<{node.pk}>')
  274:         logger.info(f'scheduled request to retrieve CalcJob<{node.pk}>')
  286:         logger.info(f'retrieving CalcJob<{node.pk}> successful')
  318:             logger.info(f'stashing calculation<{node.pk}>')
  336:         logger.info(f'stashing calculation<{node.pk}> successful')
  369:         logger.info(f'scheduled request to kill CalcJob<{node.pk}>')
  377:         logger.info(f'killing CalcJob<{node.pk}> successful')

aiida/engine/processes/workchains/workchain.py:
  332:         self.logger.info('received callback that awaitable %d has terminated', awaitable.pk)

aiida/manage/external/rmq.py:
  194:             LOGGER.info('not continuing process<%d> which is already terminated with state %s', pid, node.process_state)

aiida/parsers/plugins/diff_tutorial/parsers.py:
  40:         self.logger.info(f"Parsing '{output_filename}'")
  61:         self.logger.info(f"Parsing '{output_filename}'")

aiida/schedulers/plugins/direct.py:
  136:                 self.logger.info('sched_join_files is True, but sched_error_path is set; ignoring sched_error_path')
  205:         self.logger.info(f'submitting with: {submit_command}')
  388:         self.logger.info(f'killing job {jobid}')

aiida/schedulers/plugins/lsf.py:
  500:         self.logger.info(f'submitting with: {submit_command}')
  727:         self.logger.info(f'killing job {jobid}')

aiida/schedulers/plugins/pbsbaseclasses.py:
  215:                 _LOGGER.info(
  262:                 _LOGGER.info(
  334:         _LOGGER.info(f'submitting with: {submit_command}')
  718:         _LOGGER.info(f'killing job {jobid}')

aiida/schedulers/plugins/sge.py:
  188:                 self.logger.info(
  225:                 self.logger.info(
  300:         self.logger.info(f'submitting with: {submit_command}')
  499:         self.logger.info(f'killing job {jobid}')
  521:             self.logger.info(

aiida/schedulers/plugins/slurm.py:
  323:                 self.logger.info(
  432:         self.logger.info(f'submitting with: {submit_command}')
  706:         self.logger.info(f'killing job {jobid}')

aiida/tools/graph/deletions.py:
   73:     DELETE_LOGGER.info('%s Node(s) marked for deletion', len(pks_set_to_delete))
   90:         DELETE_LOGGER.info('This was a dry run, exiting without deleting anything')
   95:         DELETE_LOGGER.info('This was a dry run, exiting without deleting anything')
  101:     DELETE_LOGGER.info('Starting node deletion...')
  103:     DELETE_LOGGER.info('Deletion of nodes completed.')

aiida/tools/importexport/archive/migrators.py:
  127:         MIGRATE_LOGGER.info('Reading archive version')
  144:             MIGRATE_LOGGER.info('No migration required')
  147:         MIGRATE_LOGGER.info('Migration pathway: %s', ' -> '.join(pathway + [version]))
  165:         MIGRATE_LOGGER.info('Extracting archive to work directory')
  188:             MIGRATE_LOGGER.info(f"Re-compressing archive as '{out_compression}'")
  202:             MIGRATE_LOGGER.info('Moving archive to: %s', out_path)

aiida/tools/importexport/dbexport/main.py:
  253:             EXPORT_LOGGER.info('No entities were found to export')
  273:         EXPORT_LOGGER.info('Finalizing Export...')
  278:         EXPORT_LOGGER.info('Exported Entities:\n  - ' + export_summary + '\n')
  280:     # EXPORT_LOGGER.info('Writer Information:\n %s', writer.export_info)

@sphuber
Copy link
Contributor Author

sphuber commented Aug 23, 2021

Initial feedback, I note that you have not removed/replaced the VERBOSE, which I imagine may mean weird behaviour for these commands:

Good point. I will address this, removing the VERBOSE option and replacing it with the VERBOSITY one.

There are 66 instances of .info( and we should probably decide if these are now better as .report(:

I think we should not change these to report, because that would change the current behavior. Also, under our definition of report and info I think it is correct that these are info messages.

The built-in `logging` module comes with a number of pre-set logging
levels, such as `DEBUG` and `INFO`. AiiDA adds the `REPORT` level, which
sits in between `INFO` and `WARNING` and is designed to add some extra
granularity of control for messages. The report level is intended to be
used for messages that are purely informational, and so not a warning,
yet they should probably be shown by default. Traditionally, `INFO` log
messages logged by module code are often a bit too verbose to always
be showing by default. That is why AiiDA sets the default loglevel to
`REPORT` allowing code, such as `WorkChain`s to emit informational
messages that are shown by default, without also forcing all `INFO`
messages to be shown, which are typically too verbose.

To make the `REPORT` level behave like a built-in level, we hot-fix the
`logging.Logger` class to also have a `report` method, such that it can
be called as one would call `debug()` or `info()`.
@sphuber sphuber force-pushed the fix/4330/cli-verbosity-control branch from 01030f5 to fb49fc6 Compare August 23, 2021 19:06
@chrisjsewell
Copy link
Member

chrisjsewell commented Aug 24, 2021

I think we should not change these to report, because that would change the current behavior. Also, under our definition of report and info I think it is correct that these are info messages.

The behaviour will already being changing though won't it? i.e. If the verdi archive and verdi node delete commands are changed to use this new VERBOSITY option, then the default log level will change from info -> report, and so the DELETE_LOGGER, MIGRATE_LOGGER and EXPORT_LOGGER will need to change their info messages to report, to be seen in the CLI?

(the archive commands have not yet been changed in this PR, so at least for now the DELETE_LOGGER would definitely need changing, and I would try out verdi node delete manually, and paste the output here)

The custom class used for the `verdi` command, `MostSimilarCommandGroup`
is renamed to `VerdiCommandGroup`. The reason for this is that it adds
new functionality, in addition to the existing functionality of
suggesting command names in case the command is not found, to
automatically add a `-v/--verbosity` option to all commands. This option
provides a choice to set the log level for the AiiDA logger. This allows
a user to control the verbosity of output that is emitted through the
logging system in a way that is consistent across all `verdi` commands.

Since through this method, the verbosity option is only added to sub
commands, the top-level commands `verdi` itself won't inherit from this
mechanism. Instead, the option is added manually and explicitly. Note
that in this case the callback of the verbosity, which sets the log
level on the profile, does not work, since for the top-level command the
verbosity option is parsed before the profile is set on the context.
That is why the processing of the verbosity is done explicitly in the
command itself.

By making the `-v` option available for all commands, the user can pass
it at only level of the sub command stack. There is one side-effect
however. Since `verdi` itself already had the `-v/--version` option,
which clashes with the `-v/--verbosity`, the `-v` shorthand for the
version option had to be removed. For consistency the `-h` shorthand for
the help flag, which is the only other option that is also available
across all commands, is also removed.

Note that this change also fixes a bug that only made the command name
suggestion functionality available at the top level but not for the sub
commands. By overriding the ``group`` method to use the same class as
the top-level `verdi` command, all subcommands should recursively have
the same functionality.

There is one subtlety where if the `cls` is set explicitly by one of the
subcommands, that should be respected. It can't simply override it with
`VerdiCommandGroup` because the subclass may have overridden the
`get_command` as well with custom functionality. This puts the onus on
the developer of subcommands with custom classes to make sure it
inherits from `VerdiCommandGroup` if it is going to overwrite the
`get_command` method and make sure it calls the super.

Finally, the ``run_cli_command`` fixture, designed to help test CLI
commands, needed to be updated to manually apply the ``VERBOSITY``
option. In testing, the sub command is direclty fetched from the module
where it is defined, instead of getting it through the ``click`` API
starting from the base ``verdi`` command. This means the functionality
that applies the ``VERBOSITY`` option is not hit and so it has to be
called manually.
The utility functions in the `aiida.cmdline.utils.echo` module are
designed to be used in CLI commands to print output to stdout or stderr
streams. This is now changed to instead log the message to the
`aiida.cmdline` logger. This logger was added in the previous commit.
The reason is that the verbosity of this logger can be controlled
through the `--verbosity` option that was added to all commands.

To match the available log levels, the `echo_report` method was added,
which, as the name suggests, logs messages at the `REPORT` level. The
`echo` method, which was used to simply print a message without a
particular prefix, logs also at the `REPORT` level, since that is the
default log level in AiiDA. This makes sense since when developers used
`echo` they probably want it to show by default, but it is not a warning
and so should not be shown when the log level is set to `WARNING`.

The `echo_highlight` method has been removed as it was essentially a
thin wrapper around functionality that is already provided by `echo`.
Instead of using the different `color` argument, one can use `echo`
using the `fg` argument which is more consistent with the interface from
`click`'s methods which are wrapped.

All remaining direct calls of `click.echo` and `click.secho` in the code
have been replaced by the relevant `cmdline.utils.echo` command to make
sure that they are properly piped through the logging system and respect
the `--verbosity` option. Note that a few instances remain, for example,
in the `verdi completioncommand` command, but this is intentional as
they should not be influenced by the `--verbosity` option.
@sphuber sphuber force-pushed the fix/4330/cli-verbosity-control branch from fb49fc6 to a1ff72c Compare August 24, 2021 11:37
@sphuber
Copy link
Contributor Author

sphuber commented Aug 24, 2021

Ah yeah, I forgot that Casper and you programmed the delete and export functionality such that info messages would be shown by default. If that is the case, then they should indeed be changed to report. Looking at those messages, I feel that they are still quite verbose and it actually makes sense to not show them by default and the user should just pass -v info to see them. But if you prefer to show those messages by default, then we change them to report ones. It is true that that would also keep current behavior so maybe that is best anyway.

In the previous commit, the `echo` utility functions were changed to go
through the logger system, instead of directly using `click.echo` to
print to stdout and stderr. Since the default log level is `REPORT` in
AiiDA, messages logged with `echo_info` will no longer be shown by
default, unless the log level is set to `INFO` or `DEBUG`. To return to
the previous behavior, all `echo_info` instances are replaced by the new
`echo_report`, unless the existing message really corresponds to info
that is a bit verbose and can be hidden by default.

Calls to `info` for the `MIGRATE_LOGGER`, `EXPORT_LOGGER` and the
`DELETE_LOGGER` are changed to `report`. The current implementation
using these loggers assumed that the default log level would be `info`
and so these messages should be shown by default. This choice was made
since this functionality is mostly called through the command line. With
the current change where the default is now `report` these messages
would no longer show up by default.
@sphuber sphuber force-pushed the fix/4330/cli-verbosity-control branch from a1ff72c to c003b19 Compare August 24, 2021 12:02
@options.DRY_RUN()
@options.FORCE()
@with_dbenv()
def delete(codes, verbose, dry_run, force):
def delete(codes, dry_run, force):
"""Delete a code.

Note that codes are part of the data provenance, and deleting a code will delete all calculations using it.
"""
from aiida.common.log import override_log_formatter_context
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still need to use this here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so no, since the logging now goes through the echo functions which essentially do this formatting. Shall I also remove the utility itself, since its only use is in the cmdline commands?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quite proably yeh, again it would be good to run some of these commands once you are done and print the terminal output here, so we can check they are still looking pretty 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uhm, there is still a problem. Even though the logging level of the child loggers is properly set on the AIIDA_LOGGER and they inherit it, they still have the default formatting. Removing these overrides will therefore return the "incorrectly" formatted log messages. I think we should still remove them, but like the log level, also change the formatter for the AIIDA_LOGGER and all its children, globally.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, commit 6340311 implements a solution for this problem by configuring a custom formatter for all loggers when the CLI is invoked.

The `VERBOSE` option is obsolete since all commands now automatically
have the `VERBOSITY` option exposed. The `VERBOSE` option was mostly
used to configure a logger (most notably the `DELETE_LOGGER`) but this
is no longer necessary. Since those loggers are children of the main
`AIIDA_LOGGER`, whose level is controlled through the `VERBOSITY`
option, the child logger will inherit its value.

Some commands used the `VERBOSE` option more as a boolean switch. To
reproduce this behavior, a utiltiy function `is_verbose` is added to the
`cmdline` module, which will return `True` if the loglevel of the
`CMDLINE_LOGGER` is equal or smaller than the `INFO` level and `False`
otherwise.

The `verdi archive` commands used an ad-hoc implementation of the
verbosity option. This has been removed and they now also rely on the
logging level that is set on the `AIIDA_LOGGER` through the global
`VERBOSITY` option.
@sphuber sphuber force-pushed the fix/4330/cli-verbosity-control branch from c003b19 to ec81d0b Compare August 24, 2021 12:41
@@ -170,11 +165,10 @@ def create(
elif archive_format == 'null':
export_format = 'null'

if verbosity in ['DEBUG', 'INFO']:
set_progress_bar_tqdm(leave=(verbosity == 'DEBUG'))
if AIIDA_LOGGER.level <= logging.INFO:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this not be <= logging.REPORT now

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(and same for other two instances below)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't see the change yet?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be there now. Were a bunch of other fixes that had to go in.

So far, the utility functions of the `aiida.cmdline.utils.echo` module
have been rerouted through the `CMDLINE_LOGGER` which properly formats
the log message with just the message itself. However, the loggers of
any other modules will inherit the formatter of the parent `AIIDA_LOGGER`
which will prefix the message with verbose content such as the
timestamp, name of the logger and more, which is not what we want for
output generated by CLI commands.

The solution is to define a custom formatter, `CliFormatter`, which is
added to the new module `aiida.cmdline.utils.log`, and which is
configured by default for the `CMDLINE_LOGGER`. The `configure_logging`
function is updated to now take a keyword argument `cli`, which when set
to `True`, will configure this new formatter for all loggers. By calling
this method with `cli=True` in the callback of the `VERBOSITY` option,
all loggers should be correctly configured to only print the message
with the log level prefixed, when invoked through the CLI.

There is one peculiarity where the `load_backend_if_not_loaded`
decorator utility also needs to call the `configure_logging` function.
The reason is that this function loads the database backend, which
indirectly calls the `configure_logging` to add the database log
handler, but this does not pass `cli=True`. This means that the CLI
specific configuration is undone.
@sphuber sphuber force-pushed the fix/4330/cli-verbosity-control branch 4 times, most recently from 28edae6 to 5998152 Compare August 24, 2021 18:17
The `override_log_formatter` and `override_log_formatter_context`
utilities of the `aiida.common.log` module were used in certain CLI
commands to temporarily change the formatter of the logger. This was
done because they used the logging system as the way to output messages
to the terminal, but the default logger prefixed messages with extensive
information such as timestamps and the name of the logger, where only
the message was required.

These utilities are no longer needed since this custom formatting for
the CLI is now done ensured by configuring the `CliFormatter` custom
formatter which takes care of only including the log level as prefix.
@sphuber sphuber force-pushed the fix/4330/cli-verbosity-control branch from 5998152 to 35fe868 Compare August 24, 2021 18:35
Copy link
Member

@chrisjsewell chrisjsewell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I think this is all good cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Control verbosity of click output
3 participants