Hi all, For notification purposes - this has been committed as of d818e0c, ready for 1.7 alpha.
https://github.com/django/django/commit/d818e0c9b2b88276cc499974f9eee893170bf0a8 The final commit integrated a bunch of suggestions from a couple of reviewers, some Python 3 fixes, and a slight rework of the Django 1.6 TEST_RUNNER compatibility fix (to reduce the number of false positives that check was providing). On the TODO list before 1.7 final: * There's some ongoing discussion about the best way to integrate the check registration process with the new app-loading ready() method; * The text of the actual messages raised by the checks framework needs a final audit. * There's lots of room for improvement in documentation, including an index of checks that Django will raise Tim has also suggested some possible improvements to the process for silencing check messages. Thanks again to Christopher Medrela for his excellent work in GSoC 2013, without whom none of this would have been possible. Yours, Russ Magee %-) On Sun, Jan 19, 2014 at 12:50 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > Hi all, > > After a long delay, I'm finally ready to merge the result of Christopher > Medrela's 2013 Summer Of Code Project - a refactor of Django's validate > management command. > > A huge thanks to Christopher for his excellent work over the summer - he > made my job as mentor very easy. > > For those that didn't follow along with the project itself - Django's > validate management command was a single monolithic block of code that > checked for name collisions, certain allowable attribute values, and so on. > It wasn't extensible in any way. > > The purpose of this refactor was to break this monolithic method up into > smaller parts, and along the way, provide a way for other apps/libraries to > hook in and provide their own checks. So, for example, GenericForeignKeys > now get validation support - this wasn't previously possible because they > are part of a contrib app, and therefore couldn't be referenced in the core > codebase. > > So - if you've got a field, model base class or model manager that needs > custom validation that you'd like to be reported in the same way as > ./manage.py validate has historically reported, you now have a way to do so. > > Or, if you've got some other system check that you'd like to perform (for > example, performing a security audit), you can hook in to the same tools. > > As part of this refactor, we've also dealt with the manifold overloading > of the term "validate" in Django's codebase. We've deprecated "validate" in > preference for the "check" command. > > A side effect of this is that the version update checks introduced in 1.6 > are now guaranteed to run every time you do runserver. To make sure you > aren't needlessly bothered once you've dealt with these issues, individual > message types can be silenced. So, for example, when you do a version > update, you may be warned about a change; once you're satisfied that you've > met that requirement, you can silence that error and never see it again. > > We also allow for different severity levels: DEBUG, INFO, WARNING, ERROR, > CRITICAL. This provides a lot more options for reporting problems that > aren't show-stoppers, but probably warrant attention (e.g., easily > identifiable performance issues). > > I've created a clean PR based on a rebased version of the code that has > been brought up to date with trunk: > > https://github.com/django/django/pull/2181 > > There are a still a couple of minor issues that may need to be addressed - > in particular, I want to do a cleanup of the language for the messages > themselves, and the documentation would probably benefit from another pair > of eyes. However, I'm happy with the way the core has shaken out; I want to > get it into core so it gets more exposure. > > Tim's review a couple of days ago also pointed out a couple of interesting > features (in particular, adding a command-line flag to silence specific > warnings) which might be nice to have, but shouldn't affect core > functionality. > > Barring objections, I'm planning to land this in time for the 1.7 alpha > (so Andrew - no cutting releases until I've had a chance to push the merge > button :-) > > So - final chance for comments and feedback before this lands! > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq848f1o7AFiVju44mtR6A8EVg45Bk0gqG9znC-GqfXnn3XQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
