On Wed, Jul 24, 2013 at 4:17 AM, Christopher Medrela < chris.medr...@gmail.com> wrote:
> Progress: I've implemented registering entry points. Now there is > `django.core.checks.register(callable)` function. There is no > `run_in_development` and `run_in_production` arguments. I've also rewritten > mechanism of triggering checking framework -- `BaseCommand.validate` calls > `django.core.checks.run_checks` instead of `get_validation_errors` (which > was > deleted) now. > > Questions: > > 1. BaseCommand.validate have an `app` optional argument to run validation > of a > particular app (if app==None then all checks are performed). > Unfortunately, with > the current checking framework, we are not able to run checks for a > particular > app. The attribute isn't used anywhere in Django except for three tests > [1] and > I don't think that this is heavily used by third party commands. So I > propose to > deprecate this attribute if it's possible. > > [1] > https://github.com/django/django/blob/master/django/contrib/auth/tests/test_management.py#L176 > What's the technical cause of needing to drop this feature? Is it because checks are no longer guaranteed to be "app specific"? Or is there some other cause? At the end of the day, I don't especially mind if we have to drop this as a feature for the new checks framework. Checks really are something that should be run in their entirety, and if you get any errors, then . However, I can see how some people might have use for running a subset of checks against a subset of the project. If we need to drop this feature, I want to make sure we're not dropping it for a good reason, not just because it would be harder to implement. > 2a. Warnings are printed with bold, yellow foreground now (errors use red > color). Is it a good choice? > Sounds good to me. > 2b. The rules of formatting error messages are that the error message > (that may > be multiline) is followed by the hint in the next line, i. e.: > > app_label.model_label: Error message. > Error message can be multilined. In that case, the first line should > be a short description and the rest should be a long description. > HINT: Hints are printed in a new line. > > If hint is missing then there is no last line. If the invalid object is a > field > or a manager, then the error message starts with > `app_label.model_label.field_or_manager_name: `. If it's neither a model, a > manager nor a field, then '?: ' is printed. Do you have any opinion about > this > style? > Sounds good to me. My only additional comment would be to indent the 2nd+ lines slightly, so that you can easily identify the first lines of a large number of multi-line errors/warnings. It might also be worth having different indentation levels for continuation, and for starting the hint. For example: app_label.model_label: Error message. Error message can be multilined. In that case, the first line should be a short description and the rest should be a long description. HINT: Hints are printed in a new line. If hints can be multiline, then they should also be indented to a new level Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
