Opened 2 months ago

Closed 2 months 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, 2 months 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, 2 months 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, 2 months ago

Easy pickings: set

comment:4 by Héctor Castillo, 2 months ago

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

comment:5 by Mike Edmunds, 2 months ago

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

comment:6 by Héctor Castillo, 2 months ago

Owner: set to Héctor Castillo
Status: newassigned

comment:7 by Héctor Castillo, 2 months ago

Has patch: set

comment:9 by Mike Edmunds, 2 months ago

Patch needs improvement: set

comment:10 by Héctor Castillo, 2 months ago

Patch needs improvement: unset

comment:11 by Mike Edmunds, 2 months ago

Triage Stage: AcceptedReady for checkin

comment:12 by Jacob Walls <jacobtylerwalls@…>, 2 months 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