Possible future compatibility naming conflict with checksetup command

[Russell Keith-Magee]

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

[Aymeric Augustin]

On 19 juin 2013, at 10:34, Russell Keith-Magee <rus...@keith-magee.com> wrote:

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

I'm not a native speaker, but it seems to me that "check" better reflects the concept we're talking about than "verify". Also, it's shorter :)

My vote would be for standardizing to "check" rather than "checksetup" — since the checking framework could check for things that aren't strictly part of the setup.

--
Aymeric.

[Elyézer Rezende]

On Wed, Jun 19, 2013 at 5:34 AM, Russell Keith-Magee
<rus...@keith-magee.com> wrote:

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

As Aymeric said, I think 'check' and 'checking framework' make more
sense rather than 'verify' and 'verifying framework'.

PS.: I am not a native speaker too.

--
Elyézer Rezende
http://elyezer.com

[Daniel Lindsley]

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

[Russell Keith-Magee]

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 %-)

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.