Hi Thomas, On Wed, Feb 5, 2014 at 10:13 PM, Thomas Güttler <[email protected]> wrote:
> Hi, > > here is some feedback to the check framework, documented at: > > https://docs.djangoproject.com/en/dev/ref/checks/ > > --- > > > {{{ > Error('error message', None) # Good > }}} > > I don't think this is "good". The "hint" should be optional. The above line > is ugly, since you don't know why there is second argument (None). > This was intended as a case of enforcing explicit > implicit. The next line in the documentation reads: {{{ Error('error message', hint=None) # Better }}} suggesting that the preferred syntax is to explicitly state that there isn't a hint. However, I can see how this might be slightly contrary to expectation for Python developers generally. I'd be interested in hearing other opinions on this. > --- > > https://docs.djangoproject.com/en/dev/ref/django-admin/#django-admin-check > > {{{ > ... > > --tag <tagname> > > The system check framework performs many different types of checks. > }}} > > Which tags are available from django? > This is something I'm hoping to add to documentation in the near future. > How can I list the available tags (django tags and my tags)? > At present, there isn't any way. However, this is an interesting feature request - adding a --listtags option to `manage.py check` that just lists the tags that are available sounds like a good idea to me. > How can I list the available checks? > This is another area that where I'm hoping to improve documentation in the future. An automated --listchecks option would be a bit harder, because individual checks aren't registered anywhere centrally. > If a check needs two minutes, it is not wise to run it on "runserver" > on development machines. Is there a way to define which tests should > be included or excluded depending on the context. For example: if > "runserver" gets called don't call tests with have tag "foo". > I accept the problem in theory, but I'm having difficulty thinking of a situation where a check would take 2 minutes. My inclination is that this would be "solved by the market" - If Django (or a third party app) were to add a plugin that had extremely slow performance in real-world conditions, people would demand that it was removed or refactored. Do you have a specific idea for a check that might take a long time to run? > ---- > > https://docs.djangoproject.com/en/dev/ref/checks/# > registering-and-labeling-checks > > {{{ > @register('compatibility') > }}} > > I don't like strings like this, since it can contain typos. > > Are there objects for common tags? Example: > > {{{ > @register(Tag.COMPATIBILITY) > }}} > > Not at present; however, that sounds like a reasonable idea. > Thank you for this check framework. I like it. > > Thanks for the review notes! You've made a couple of really good suggestions here. 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq84_k7-Pv-_JVQNEMpFhM0M%3Dgc_z%2BTDBwXxiMLphSyXV6KQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
