#21197: 1.6 compatibility checks don't correctly validate TEST_RUNNER
-------------------------------------+-------------------------------------
Reporter: russellm | Owner: nobody
Type: Bug | Status: new
Component: Core (Management | Version:
commands) | 1.6-alpha-1
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by carljm):
Hi Russ - I think I must be missing something key, because I'm having
trouble making sense of your response :-)
Replying to [comment:3 russellm]:
> Consider case 2. A user has an old 1.5 project. They run check, and they
get the error. They update their project. They run check again, and they
get the same error. As an end user, this could be easily interpreted as
"Whatever I did didn't work, so what do I need to fix".
How would a user "run check and get the error" on "an old 1.5 project",
considering that this check didn't exist in 1.5?
When you say a "A pre-Django 1.6 project with TEST_RUNNER set to
DiscoverRunner" I made the assumption that you were talking about the
externally-packaged `DiscoverRunner`, because the internal-to-Django
`DiscoverRunner` does not exist pre-1.6. If you're talking about the
externally-packaged one, its users obviously use a different `TEST_RUNNER`
setting, so they wouldn't get the error. If you're talking about Django's
new `DiscoverRunner`, I'm not sure how case 2 is possible.
> In case 3, they're always going to get the error. At the very least,
there should be a *different* error message, saying "Django doesn't know
what to do here"; but it should be possible to do some issubclass checks.
It seems like you've got the sense of the "if" check backwards? Case 3 is
"A pre-Django 1.6 project with TEST_RUNNER set to something custom" -- if
`TEST_RUNNER` is set to something custom, they will never get the error.
The error only occurs if `TEST_RUNNER` is at its default value, the reason
being that the check is supposed to catch people who are just using the
default test runner, for whom the default will change when they upgrade to
1.6.
> Case 5 *should* never happen -- there's no reason to run check on a 1.6
project -- but if you do, you're going to get an error. Looking longer
term (and the reason why this came to my attention), the GSoC validation
project means this check will be run as part of the prestart checks for
syncdb and runserver, so it's important that we can correctly identify
that there's nothing wrong with the current project.
Again, in case 5 they will never see the error.
It's case 4 that is a problem, and the problem is simply that this check
was not written for a world where it would be run constantly.
> The crux of this problem is that we can't tell the difference between
"Letting the default fall through" and "Explicitly set". If we modify the
global_setting default to something identifiable, we have a way around
this problem. I should have a chance to look at this today; I'll report
back with a patch.
Although I think it's case 4, not 2/3/5, that need attention, I agree that
this is the crux of the immediate problem. It's a problem we've run into
before and will run into again in similar situations, so I'd prefer to see
a generic resolution than one that only works for the `TEST_RUNNER`
setting.
I also think shai has correctly identified a different angle on the
problem, which is that it would be nice to have a "this project currently
expects Django version X" setting, so that if we are running checks in
Django 1.6 on a project set to expect 1.5, we can warn about anything that
might be an issue for that upgrade without having to always be so clever
about trying to figure out their exact configuration. Once they've dealt
with those warnings (if necessary), they can simply update their settings
to say "expects Django 1.6" and never see any of those warnings again.
--
Ticket URL: <https://code.djangoproject.com/ticket/21197#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.3d8bd660151fd573686e48252e9a0f1b%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.
