ImproperlyConfigured: You must enable 'django.core.context_processors.request' in TEMPLATE_CONTEXT_PROCESSORS

[Ivan]

After revision r17598 django.core.context_processors.request is lost from the settings.TEMPLATE_CONTEXT_PROCESSORS.
And all tests, that uses "requiest", - fall.

[Carl Meyer]

Yes, this is a problem. If the contrib.auth tests are really to be properly isolated, r17598 needed to go further and override TEMPLATE_DIRS as well and add test templates for the contrib.auth views. Of course, at that point there is little to no reason why the contrib.auth tests should be run in anyone's project, and they may as well be moved to Django's own test suite.

Marking this a release blocker as it's a regression. If nothing else, r17598 should just be rolled back.

[Carl Meyer]

Oh, I just realized that r17598 itself fixed a release-blocking regression (#16366).

The more we have to isolate contrib-app tests from the project settings, the less justification there is for even having those tests run in anyone's project. Until we achieve perfect isolation, we'll keep getting reports of failures due to differences in someone's setup. Once we achieve perfect isolation, having those tests run by default just uselessly slows down people's test suites with extra tests that will never fail (unless they are mucking in contrib.auth's own codebase).

It's possible there could be a few integration tests that are not isolated and must pass in any project where contrib.auth is functioning, but I doubt that it is even possible to write such tests and have them still be useful, given all the possible customizations of contrib.auth in a given project. Such integration tests should be provided by the project, which knows how their integration works, not by contrib.auth.

So I think the real fix to this and #16366 is just to place contrib.auth's tests in Django's own test suite instead, or in a submodule of contrib.auth such that they only run if you place "contrib.auth.tests" in the installed apps.

[Ivan]

Carljm, thanks for answer.

Are you sure, that issue in contrib.auth and not in django.test.utils.override_settings() logic?

I'm afraid, that some yet another 3rd application can kill data from settings...

[Carl Meyer]

Replying to EvoTech:

Carljm, thanks for answer.

Are you sure, that issue in contrib.auth and not in django.test.utils.override_settings() logic?

I'm afaide, that some yet another 3rd application can kill data from settings...

I'm fairly sure override_settings is working as designed. It only overrides the settings for the duration of those tests, which is what it should do and is fine. It's not "killing data from settings" in any persistent way.

But I just realized that much of my comments here are wrong and based on an insufficiently careful scan of the changeset. TEMPLATE_DIRS are of course overridden for those tests both before and after r17598. Given that, I no longer understand how r17598 could cause tests to fail in your project. So I'm closing this needsinfo - can you paste the failure you are seeing since r17598, and your project's settings file?

Clearly time for me to quit for the night...