#21429: BaseCommand should use logging instead of custom output wrappers
-------------------------------------+-------------------------------------
Reporter: Nical | Owner: François
| Freitag
Type: New feature | Status: assigned
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: command output | Triage Stage: Accepted
logger |
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by François Freitag):
An update after about 2 months. There is still a good chunk of work left,
to clean-up commits, prepare for the transition, update the documentation,
etc. but the work is taking shape: all management commands have been
updated to use a logger, tests updated accordingly and the test suite
passes.
In my draft, there’s a main logger for all commands, `django.command`, and
a logger dedicated to report progress of commands `django.progress` that
uses `\r` as a terminator. I’m planning on splitting `django.command` to
have a logger per command, e.g. `django.command.migrate`, all with
`django.command` as their parent. That will facilitate redirecting the
output of a particular command while relying on the parent behavior
otherwise.
Notable changes:
- `CommandError` assumed the message was interpolated. A `logger_args`
keyword
argument was introduced to pass variable arguments separately
(https://docs.python.org/3.8/howto/logging.html#logging-variable-data).
- Format placeholders are generated for messages where a variable number
of
arguments is used, in order to pass the variable data separately from
the
message. For example, a message listing issues in apps was previously
logged
as `"\n".join(variables)`. To log variable data separately, the message
becomes
`"\n".join(["%s"] * len(variables))`.
Left out of scope:
Some commands directly raise the message from an exception they caught as
a `CommandError`.
Ideally, variable data would be separated from the message, so that the
logger handles the variable data separately. However, the exceptions are
generated by other modules, which do not know how the exception will be
used.. In these cases, I’m using the interpolated error message for the
`CommandError`, not logging variable data separately. This can be improved
upon at a later stage.
--
Ticket URL: <https://code.djangoproject.com/ticket/21429#comment:15>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.d666e8faeb402425dca45a6208eb0150%40djangoproject.com.
