Hi, Carl,

On 09/27/2013 09:01 PM, Carl Meyer wrote:
> Hi Ivan,
> 
> On 09/27/2013 03:07 AM, Ivan Kharlamov wrote:
>> Maybe I'm a careless kind of guy, but when I test out new versions of
>> Django, reading all of the release notes is rarely the first thing that
>> I do... my bad. :) My first action is usually firing up the test suites
>> and looking at the number of failed tests and deprecation warnings.
>>
>> As we all know, Django-1.6 is special in this regard, since it doesn't
>> run all the tests that the previous version would've discovered. Since
>> it doesn't raise any deprecation warnings, it becomes really easy to
>> assume that everything is fine and that the project is Django-1.6 ready,
>> when in fact it is completely broken.
>>
>> Perhaps, Django-1.6 test runner could raise a warning and inform the
>> user that the number of tests that would've run on the previous
>> versions, was omitted.
>>
>> My wild guess is that the lack of a deprecation warning is just asking
>> for some wildly entertaining user stories.
>>
>> What do you think?
> 
> Thanks for reporting on your experience. I see (and was already aware
> of) the problem, but all the solutions I see are ugly in one way or
> another. Some options:
> 
> 1) The status quo. If people run the new "manage.py check" command,
> they'll get a warning directing them to the release notes. But given
> that "manage.py check" is new, its unlikely anyone would run it unless
> they've already read the release notes, so this isn't worth much.
> 
> 2) The new test runner issues some kind of warning unconditionally on
> 1.6 (this seems to be what you're proposing). That would certainly catch
> the people we need to catch, but it seems like an awfully big hammer.
> Once you know about the new test runner and have adjusted your tests,
> wouldn't it be irritating to keep seeing that warning every single time?
> And people creating new 1.6 projects would be irritated too, since the
> warning is useless to them.
> 
> 3) A first-run warning that can be turned off (and presumably would be
> off by default in new projects). The obvious mechanism for turning it
> off would be something in settings. That either means introducing a new
> setting specifically for this warning, or warning anybody who doesn't
> have an explicit TEST_RUNNER override (meaning all 1.6 projects would be
> required to needlessly specify the new test runner in their settings in
> order to silence the warning.)
> 
> 4) A variant of (3) where we introduce a more general setting that we
> can use for similar situations in the future. Something like a
> SILENCE_UPGRADE_WARNINGS setting that's a list or set of well-known
> strings, or something: SILENCE_UPGRADE_WARNINGS = ['discovery-runner']
> or some such.
> 
> 5) The new test runner, every time its run, goes out and looks for tests
> in the locations where the new runner won't find them (models.py files,
> app tests/__init__.py files, tests.py in INSTALLED_APPS that are not
> within the CWD, doctests) and warns you if it finds any. This would be a
> fair chunk of code that would be easy to get wrong, and I think it's
> really too late to add it to 1.6. It would also slow down test-running
> unnecessarily on every run.
> 
> So, like I said, a bunch of bad options. Which is the least bad?
> Personally I'd be open to considering (1), (3), or (4). Interested in
> others' thoughts.
> 
> Carl
> 

Thank you for considering a fix!

Personally, I'd prefer a solution proposed by Shai, which is (5).

As another alternative to creating a new variable in settings.py, there
is an option, albeit also a little bit ugly, to add a command line
parameter, so that the tests could be run with './manage.py test
application --no-upgrade-warning'.

With best wishes,
Ivan

P.S.
I've recently found another minor bug in the new test runner:
https://code.djangoproject.com/ticket/21206#ticket

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/524AC1D4.3040909%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to