Hi Shai, On 09/27/2013 05:42 PM, Shai Berger wrote: > On Friday 27 September 2013 20:01:00 Carl Meyer wrote: >> 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. >> > I think in view of the GSoC work and the check command, (4) as phrased above > would be mostly duplication of effort. The 'check' command, IIRC, already > includes mechanisms to silence specific warnings. > > I think my preferred solution is a mix of your (3) and (5) -- a search for > tests that can be turned off. I think (though I'm not too familiar with that > area of the code) that the coding here is not too hard -- essentially, run > the > old code as well as the new code for building the test-suite, and diff the > results.
I think (5) -- searching for tests using the old and new runners and comparing results -- is more attractive in theory than it is useful in practice. Because the new test runner does not run tests in "external" apps by default, it will always run a different set of tests than the old runner (except in the rare case of a project that uses no contrib apps or pip-installed apps with tests). So if we compare the set of collected tests, we will basically always get different results, and always issue the warning. So in practice it reduces to almost the same thing as an always-issued warning, but with more code and moving parts to achieve the same result. I don't think it's worth it. Which brings us to the same problem we had before - the best way to turn off a warning you would otherwise always get. > Another idea is a variation on your (4) -- add a setting to specify the > Django > version expected by the project; so if a project says, for example, > DJANGO_USED="1.5", we emit suitable upgrade warnings. > > This may have a problem -- it may create unwarranted expectations of backward- > compatibility support; people may think it tells newer Django versions to use > the behavior of older versions, rather than warn on breaking changes. But I > do > find it has a certain appeal -- it's a lot like including the protocol > version > in messages. I agree that this idea would allow us to be a lot smarter about certain upgrade warnings. Carl -- 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/524B7BB8.4080803%40oddbird.net. For more options, visit https://groups.google.com/groups/opt_out.
