#22993 closed Cleanup/optimization (fixed)
Drop skipIfCustomUser decorator
| Reported by: | Tim Graham | Owned by: | Chris Luc |
|---|---|---|---|
| Component: | contrib.auth | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | yes | UI/UX: | no |
Description
With the test discovery changes in 1.6, the tests for django.contrib apps are no longer run as part of user's project. For this reason I believe we no longer need to decorate tests in contrib.auth with @skipIfCustomUser.
Change History (11)
comment:1 by , 10 years ago
| Triage Stage: | Unreviewed → Someday/Maybe |
|---|
comment:2 by , 10 years ago
| Triage Stage: | Someday/Maybe → Accepted |
|---|
Can we still deprecate it in 1.8? That way developers can use it through the LTS version and only need to upgrade to the next LTS after 1.8 and we can get rid of it in 2.0. If deprecation time for 1.8 is already over, let's do it for 1.9. Either way should give users plenty of time to update their test suite.
comment:3 by , 10 years ago
I'm not quite understanding your argument for why it would be advantageous to deprecate for 1.8. I think 1.9 is fine.
comment:4 by , 10 years ago
Django's auth tests no longer use that decorator. Is the decorator still useful for reusable apps developers (then this bug can be closed)? Or do we want to remove the decorator from contrib.auth (it is currently documented)?
comment:5 by , 10 years ago
I don't know of any apps that ship tests that are designed to run as part of your project which would be the reason for the decorator. If we remove it from Django (after deprecation since it's documented) It's easiest enough to copy it into your project if you need it.
comment:6 by , 10 years ago
| Easy pickings: | set |
|---|
comment:7 by , 10 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:8 by , 10 years ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
comment:9 by , 10 years ago
| Has patch: | set |
|---|---|
| Triage Stage: | Ready for checkin → Accepted |
Hi Chris, the Ready for checkin flag is only set when someone else has reviewed your patch. Just set the Has patch flag when your pull request is ready.
django-developers thread. Consensus seems to be that we shouldn't drop it now because of projects that may still be using the old test runner.