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 -- 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. For more options, visit https://groups.google.com/groups/opt_out.
