Add verbosity option to manage.py checks that outputs which checks are ran

[Gordon]

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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/85259884-52fa-42b2-822f-f0537f5b2f0bo%40googlegroups.com.

I need a mentor on django

[Onayemi Hakeem]

I need a mentor who can guide me on my Django programming skill to develop my 
dream app

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8b4b8a83-aee6-4c84-acf5-3f0cdf3c03d2o%40googlegroups.com.

Re: Add verbosity option to manage.py checks that outputs which checks are ran

[Adam Johnson]

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]:
[,
 ,
 ...
 ]

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  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 django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/85259884-52fa-42b2-822f-f0537f5b2f0bo%40googlegroups.com
> 
> .
>


-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3793nm6FSt4dKOtn2qNF%2B5A1%3Dyn3HvHiTdmaSJ3s4VYQ%40mail.gmail.com.

Re: I need a mentor on django

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/3.0/faq/help/ . This will help you find
people who are willing to support you, and to ask your question in a way
that makes it easy for them to answer.

Thanks for your understanding and all the best,

Adam

On Wed, 10 Jun 2020 at 16:52, Onayemi Hakeem 
wrote:

> I need a mentor who can guide me on my Django programming skill to develop
> my dream app
>
> --
> 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 django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/8b4b8a83-aee6-4c84-acf5-3f0cdf3c03d2o%40googlegroups.com
> .
>


-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2gOnUKGM%2BFcEwLRN_TKT20jkbjJjoXs1tQkgoh_gov%2Bw%40mail.gmail.com.

Re: I need a mentor on django

[patels.manit]

Hi 
You can ask me for help


On Wednesday, June 10, 2020 at 9:27:29 PM UTC+5:30, Onayemi Hakeem wrote:
>
> I need a mentor who can guide me on my Django programming skill to develop 
> my dream app

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2fe145aa-47df-4e9b-bf6e-46c098506e90o%40googlegroups.com.

Re: I need a mentor on django

[Onayemi Hakeem]

Okay if that is the case I agreed I've been in the wrong mailing list can
you please add or refer to a platform where I can be mentored, or assisted
whenever I ran into problems using django

On Wed, Jun 10, 2020, 17:11 Adam Johnson  wrote:

> Hi!
>
> I think you've found the wrong mailing list for this post. This mailing
> list is for discussing the development of Django itself, not for support
> using Django. This means the discussions of bugs and features in Django
> itself, rather than in your code using it. People on this list are unlikely
> to answer your support query with their limited time and energy.
>
> For support, please follow the "Getting Help" page:
> https://docs.djangoproject.com/en/3.0/faq/help/ . This will help you find
> people who are willing to support you, and to ask your question in a way
> that makes it easy for them to answer.
>
> Thanks for your understanding and all the best,
>
> Adam
>
> On Wed, 10 Jun 2020 at 16:52, Onayemi Hakeem 
> wrote:
>
>> I need a mentor who can guide me on my Django programming skill to
>> develop my dream app
>>
>> --
>> 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 django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/8b4b8a83-aee6-4c84-acf5-3f0cdf3c03d2o%40googlegroups.com
>> .
>>
>
>
> --
> 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 django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2gOnUKGM%2BFcEwLRN_TKT20jkbjJjoXs1tQkgoh_gov%2Bw%40mail.gmail.com
> 
> .
>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BRvhbTFZPOo4qc2jrE9NLQH4cDJ5tgcmL1kzSqG%2BERueoAEQA%40mail.gmail.com.

Re: Add verbosity option to manage.py checks that outputs which checks are ran

[Gordon]

Particular case that spurred this - reusable app had checks to make sure 
urls were reversible.  Checks weren't imported.  Checks command passes but 
doesn't run the apps checks.  There is no indication that the checks were 
not run so you have to assume they did and were successful.

The app checks were tested for function.  Since this imports the checks 
they would show as registered using your `get_checks()` test, no?  Seems 
kind of tricky...

Since the checks framework is meant to be "extensible so you can easily add 
your own checks", it just seems like some sort of indication about which 
checks are run makes sense.  They are a great way for checking runtime 
conditions against production settings but not being able to confirm they 
actually ran somewhat negates the peace of mind that all is well.

Thanks,
Gordon



On Wednesday, June 10, 2020 at 11:59:39 AM UTC-4, Adam Johnson wrote:
>
> 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]:
> [ **kwargs)>,
>   django.core.checks.urls.check_url_namespaces_unique(app_configs, **kwargs)>,
>  ...
>   **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 > 
> 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 django-d...@googlegroups.com .
>> To view 

Re: Add verbosity option to manage.py checks that outputs which checks are ran

[Adam Johnson]

Perhaps there could be better on guidance in the documentation about
registering custom checks. I see nothing in the "writing your own checks"
guide really describes a recommended code structure. We'd accept a docs PR
there I'm sure.

I normally have a checks submodule in my app and register the checks in
AppConfig.ready(). For example:
https://github.com/adamchainz/django-mysql/blob/2cf93c771f16011bc754a61e5aa95be4871f0363/src/django_mysql/apps.py#L17
. I don't like the decorator form since that's an import side effect and as
you've discovered it's not always easy to ensure your module gets imported.

On Wed, 10 Jun 2020 at 21:16, Gordon  wrote:

> Particular case that spurred this - reusable app had checks to make sure
> urls were reversible.  Checks weren't imported.  Checks command passes but
> doesn't run the apps checks.  There is no indication that the checks were
> not run so you have to assume they did and were successful.
>
> The app checks were tested for function.  Since this imports the checks
> they would show as registered using your `get_checks()` test, no?  Seems
> kind of tricky...
>
> Since the checks framework is meant to be "extensible so you can easily
> add your own checks", it just seems like some sort of indication about
> which checks are run makes sense.  They are a great way for checking
> runtime conditions against production settings but not being able to
> confirm they actually ran somewhat negates the peace of mind that all is
> well.
>
> Thanks,
> Gordon
>
>
>
> On Wednesday, June 10, 2020 at 11:59:39 AM UTC-4, Adam Johnson wrote:
>>
>> 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]:
>> [> **kwargs)>,
>>  > django.core.checks.urls.check_url_namespaces_unique(app_configs, **kwargs)>,
>>  ...
>>  > **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  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