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/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.
