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)

comment:1 by Jacob Walls, 3 weeks ago

Triage Stage: UnreviewedAccepted

Thanks, I can see how this makes testing the assertions themselves more difficult. (I'll leave Testing Framework as the component in that case.)

(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.

in reply to:  1 comment:2 by Mike Edmunds, 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 Mike Edmunds, 3 weeks ago

Easy pickings: set

comment:4 by Héctor Castillo, 3 weeks ago

Hi, I’d like to work on this issue.

comment:5 by Mike Edmunds, 3 weeks ago

Welcome Héctor. Please follow Django's contributor docs starting with "Claiming" tickets.

comment:6 by Héctor Castillo, 3 weeks ago

Owner: set to Héctor Castillo
Status: newassigned

comment:7 by Héctor Castillo, 3 weeks ago

Has patch: set

comment:9 by Mike Edmunds, 3 weeks ago

Patch needs improvement: set

comment:10 by Héctor Castillo, 3 weeks ago

Patch needs improvement: unset

comment:11 by Mike Edmunds, 3 weeks ago

Triage Stage: AcceptedReady for checkin

comment:12 by Jacob Walls <jacobtylerwalls@…>, 3 weeks ago

Resolution: fixed
Status: assignedclosed

In f8c0a93:

Fixed #37080 -- Filtered by generic deprecation warnings in runtests.py.

Note: See TracTickets for help on using tickets.
Back to Top