> > Aside: I think the `.urls = ...` -> `@override_settings(ROOT_URLCONF=...)` > change to test cases is missing from those notes? >
The 1.10 release notes say, "SimpleTestCase.urls is removed." > I expected to have seen a deprecation warning when running the tests under > 1.9, although wasn't exactly sure if and when those warnings would be > displayed. > Deprecation warnings are loud by default when using "manage.py test", however, I've removed that behavior starting with Django 1.11 as per https://docs.djangoproject.com/en/dev/releases/1.11/#deprecating-warnings-are-no-longer-loud-by-default. I'll probably duplicate those tips in the "how to upgrade Django" doc (https://docs.djangoproject.com/en/dev/howto/upgrade-version/). (The behavior still isn't ideal then as each instance of warning is output > once every time for each occurrence, rather than once and once only) > I don't think it's a sensible default to see each warning once rather than each time the deprecated behavior is invoked. For some warnings it might make sense, but for others, then you'd have to rerun the test suite after fixing each warning to see if the warning pops up elsewhere (unless I'm missing your rationale?). > The upshot of all this is that I believe many of our users are likely to > be hitting problems with upgrades because they're not seeing deprecation > warnings, and then get hit by a behavioral change that they weren't > expecting to have to deal with, and end up having to debug the cause of. > I guess this is currently limited to anyone not using "manage.py test", but will affect all users starting with Django 1.11 per the previously mentioned changed. > For instance, a user is running under 1.9 and wants to upgrade to 1.10. > Could we have a reliable and documented mechanism by which they'd first run > the tests under 1.9, and have any Deprecation warnings treated as errors? > If they're running 1.8, could we document how to run the tests so that any > PendingDeprecation warnings are treated as errors? > warnings.simplefilter("error", RemovedInDjango20Warning) With the latest deprecation/release schedule, I think technique described in the 1.11 release notes should work for the majority of cases. If projects want to support consecutive LTS releases, they shouldn't worry about deprecation warnings until a "dot zero" release, at which point they should follow the tip and fix all warnings. > Could we collate instances of these warnings, rather than displaying them > in an overly verbose fashion? > I'm against adding custom behavior in Django (like what's been removed in https://github.com/django/django/commit/5b94b17feff15a9f0345f92fc0568bfe7038e3a3) that makes warnings work differently from in Python. > An example of the sort of thing we could do might be to have an > environment variable `DJANGO_UPGRADE`, that if set to a version number, > forces the relevant class of deprecation / pending deprecation warnings to > be written to a log file or similar. I don't think that interface is quite > right, but suggesting it as an example of how we might make our user's > lives easier. > I've never had trouble with the console output format myself, but I suppose you could experiment with some third-party package that does what you want and we'll see if people find it useful. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1ede7c88-41d2-40ca-a1da-a6e3f345ad49%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
