Hi all (but especially Daniel) I've got a quick question about a recent commit and some naming consequences that I think we need to sort out before we cut the 1.6 beta.
tl;dr - I think we either need to rename the recently added checksetup command, or do some light refactoring of it's internals so that we don't make a rod for our own backs with work landing through the GSoC. In a recent commit [1], Daniel introduced a new management command - checksetup - that can be used to identify upgrade-related issues in your Django configuration -- in this case, the TEST_RUNNER problem, but he's set up a framework that allows for other checks in the future. There's some interesting overlap here between this command, and the work of my GSoC student, Christopher Medrela. Chris' GSoC project is about refactoring the `validate` management command, turning the current monolithic validation mechanism into something that is more easily extensible. Along the way, the aim is to introduce validation warnings as well as errors, and provide ways to silence those warnings if needed. As part of this work, we're addressing the fact that `validate` is a badly overloaded word in Django at this point -- we have model validation, form validation, and `validate` which performs system checks. This is particularly problematic because we're looking at factoring 'validation' system checks out into models and fields… which already have validate methods to handle model validation. So - we've been looking for a new name. Two days before Daniel committed his patch and new `checksetup` management command, Christopher and I were having a discussion about a suitable alternative name for a new, refactored `validate` command [2]. The end goal would be to deprecate validate in favour of the new name. The mailing list discussion kicked around a few names, and we'd broadly settled on `verify`. `check` (and some variants) was also considered. Chris' preference was for verify. I'm on the fence. I don't love `verify` as a name, but I'm willing to call it a bike shed on my part. In line with this, fields, models, and anything else requiring on-startup checks will be gaining a verify() entry point that users can use to add their own verification checks. However, Daniel's commit has forced the issue, because we now have a checksetup command whose implementation and use is a simple version of what we're targeting for the GSoC. So, do we: 1) Keep checksetup as a name, and integrate the GSoC work under that new name (including making the API entry points called check() or checksetup() ). 2) Rename `checksetup` to `verify`, setting the groundwork for the GSoC to expand on the implementation that is already there 3) Keep both commands. Opinions? I don't think (3) is the way to go - I'm not sure how we'd explain the existence of both commands. I could go either way on (1) or (2) though -- I'm not in love with either name, we just need to pick one. Either way, this also means there's some scope for refactoring -- django.core.compat_checks is a bit of a wart of a name against the rest of the django.core namespace, IMHO. Chris is going to have a need for a bunch of verify/check related utilities, not the least of which are classes for defining Verify/Check Errors and Warnings, so we have an opportunity to create django.core.verify.compatiblity (or django.core.check.compatibility) to store the compatibility checks, and django.core.check.utils to store the helper pieces. Yours, Russ Magee %-) [1] https://github.com/django/django/commit/91f317c76d503b4bcae5a26c230425944dbf4ea8 [2] https://groups.google.com/d/msg/django-developers/fEf21dtpqDE/YqxM_OopbHcJ -- 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. For more options, visit https://groups.google.com/groups/opt_out.
