Opened 3 weeks ago
Closed 3 weeks ago
#37080 closed Cleanup/optimization (fixed)
Django's own tests should always treat both Django deprecation warnings as errors
| Reported by: | Mike Edmunds | Owned by: | Héctor Castillo |
|---|---|---|---|
| Component: | Testing framework | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Ready for checkin | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | yes | UI/UX: | no |
Description
Django's runtests.py treats RemovedAfterNextVersionWarning (currently equivalent to RemovedInDjango70Warning) as an error, in all releases. And in x.0 and x.2 releases, it also treats RemovedInNextVersionWarning as an error.
However, in x.1 releases RemovedInNextVersionWarning is not handled as an error (because there is no RemovedInDjango62Warning, or any x.2 equivalent).
This doesn't matter for most Django tests, which use the concrete RemovedInDjango70Warning, RemovedInDjango71Warning, etc. But it complicates testing Django's own deprecation utilities and assertion helpers, and it makes discussions of them complicated.
Suggestion: change runtests.py to use the generic warnings and treat them both as errors—always, without the need to advance them each release:
# Before: warnings.simplefilter("error", RemovedInDjango70Warning) # After warnings.simplefilter("error", RemovedInNextVersionWarning) warnings.simplefilter("error", RemovedAfterNextVersionWarning)
(I think this becomes moot if/when we switch to calendar cycle releases.)
Change History (12)
follow-up: 2 comment:1 by , 3 weeks ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:2 by , 3 weeks ago
Replying to Jacob Walls:
(I think this becomes moot if/when we switch to calendar cycle releases.)
Can you expand on that part? I'm assuming that part wouldn't change.
The DEP 20 deprecation policy doesn't have the X.0 special cases that result in RemovedInDjango62Warning not existing, so being omitted from the runtests.py filters. There will always be two concrete RemovedIn warnings defined…
# Django 2028.x: # RemovedInNextVersionWarning (DeprecationWarning): warnings.simplefilter("error", RemovedInDjango2029Warning) # RemovedAfterNextVersionWarning (PendingDeprecationWarning): warnings.simplefilter("error", RemovedInDjango2030Warning)
comment:3 by , 3 weeks ago
| Easy pickings: | set |
|---|
comment:5 by , 3 weeks ago
Welcome Héctor. Please follow Django's contributor docs starting with "Claiming" tickets.
comment:6 by , 3 weeks ago
| Owner: | set to |
|---|---|
| Status: | new → assigned |
comment:7 by , 3 weeks ago
| Has patch: | set |
|---|
comment:9 by , 3 weeks ago
| Patch needs improvement: | set |
|---|
comment:10 by , 3 weeks ago
| Patch needs improvement: | unset |
|---|
comment:11 by , 3 weeks ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
Thanks, I can see how this makes testing the assertions themselves more difficult. (I'll leave Testing Framework as the component in that case.)
Can you expand on that part? I'm assuming that part wouldn't change.