Closing the loop - I opened #20653 to track this issue. Consensus seems to be that check is the best name on offer, so I've committed that change in in 03465639.
Russ %-) On Thu, Jun 20, 2013 at 12:53 PM, Daniel Lindsley <[email protected]>wrote: > Russ, > > > Apologies for forcing the issue & for making a mess of the > ``django.core`` namespace. The goal was to help improve the user experience > of sanity-checking their kit, but it seems I did more harm than good. > > I'm fine with unifying the two (with option #2 probably being more > likely so as not to disrupt the GSoC project any further). I am not opposed > to either ``check`` or ``verify``. Both are perhaps a bit too generic for > my taste ("what are you checking (or verifying)?"), but they are much more > concise than using ``./manage.py > checkmyapplicationsettingsandcodeforcompatibilitywiththisdjango``, so I'm > in favor. The upshot is that since it's new, very little should be > depending on what was committed, as I didn't get the chance to submit > patches to other projects/apps to integrate it yet. > > In short, whatever the consensus, I'm happy to change it (or help (or > get out of the way)). > > > Daniel > > > > > On Wednesday, June 19, 2013 1:34:54 AM UTC-7, Russell Keith-Magee wrote: >> >> 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/** >> 91f317c76d503b4bcae5a26c230425**944dbf4ea8<https://github.com/django/django/commit/91f317c76d503b4bcae5a26c230425944dbf4ea8> >> [2] https://groups.google.com/d/**msg/django-developers/** >> fEf21dtpqDE/YqxM_OopbHcJ<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. > > > -- 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.
