I am with Mariusz. Displaying the names of the check functions is a bit against the intention of the checks framework. The check ID's are intended to be enough information to reference the problem. This is different to unit tests, where the function names are intended to carry information.
Django doesn't really have a useful structure to its check function names. For example a single check function, check_all_models() , is responsible for all model level checks ( https://github.com/django/django/blob/678c8dfee458cda77fce0d1c127f1939dc134584/django/core/checks/model_checks.py#L12 ). This has its own call tree through to Model.check() then each field's Field.check(). Outputting a list entry like "check_all_models WARN" would not give any actionable information. If you want to debug your own checks: 1. Write tests for them. For example, use override_settings() in a test case to set a setting to the value that would cause a warning, and check that it returns the correct list of CheckMessage objects. 2. You can inspect which check functions are registered with the undocumented get_checks() function of the registry: In [1]: from django.core.checks.registry import registry In [2]: registry.get_checks() Out[2]: [<function django.core.checks.urls.check_url_config(app_configs, **kwargs)>, <function django.core.checks.urls.check_url_namespaces_unique(app_configs, **kwargs)>, ... <function django.contrib.auth.checks.check_user_model(app_configs=None, **kwargs)>] If you're particularly unconfident that your checks.register() lines don't always work, perhaps because they're conditional, you can also write unit tests that run get_checks() and see your check functions are registered. On Wed, 10 Jun 2020 at 15:00, Gordon <[email protected]> wrote: > This is a discussion for https://code.djangoproject.com/ticket/31681 - > the feature would be useful to me and seems like something generally useful > as well since it is implemented in the testing framework. The closing > comment mentions that copying a documentation page into command output > isn't valuable. That isn't what I meant to suggest so I will attempt to > explain more clearly below: > > It would be helpful if `checks` would output what checks it is running. > Currently you don't actually know if a check runs or not. Perhaps it isn't > registered correctly? Or it was excluded by mistake when you expected it > to run? I like to keep this information around in build history for quick > inspection purposes as needed. > > > For example, when running a check it would be nice to (optionally) see > something of the form: > > - path.to.my.checkA ... ok > - path.to.my.checkB ... ERROR > - path.to.my.checkC ... ok > - path.to.my.checkD ... WARN > > System check ran 100 checks and identified 2 issues (0 silenced). > > > > It would be helpful if the `checks` verbosity flag worked in similar > fashion to the testing framework. I am thinking that `-v 1` or unspecified > would maintain the current behavior. `-v 2` outputs all checks run not > under the django namespace (due to the comment in the ticket about not > repeating a documentation page). And `-v 3` outputs all checks. It might > also be helpful to add a verbosity level that only prints checks under the > current working directory (i.e. project specific checks) but this might be > difficult to determine correctly based on project layout and installation > method. > > If the general consensus likes the feature and the issue can be re-opened, > I will investigate. The ticket says it would not be feasible to output > this information. I am assuming (since they are run generically via a > registration approach) that it should be straightforward to log the dotted > path of the check. > > Please let me know what you think! > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/85259884-52fa-42b2-822f-f0537f5b2f0bo%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/85259884-52fa-42b2-822f-f0537f5b2f0bo%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Adam -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM3793nm6FSt4dKOtn2qNF%2B5A1%3Dyn3HvHiTdmaSJ3s4VYQ%40mail.gmail.com.
