pytest-django
pytest-django copied to clipboard
pytest-dev
Modifying INSTALLED_APPS with the settings fixture does not update the app registry
I don't have an obvious simple test case ready, but I can try to cook one up later. The gist is that when I wanted to insert a new package to INSTALLED_APPS during tests, I had to use django.test.modify_settings, because just appending a new entry to the settings using the fixture didn't trigger a reload of models, and, by consequence, the models' relation graphs didn't get populated.
A test for this would be nice, maybe with (https://github.com/pytest-dev/pytest-django/blob/74c271095ef385ca0cc696e725e33ce6a41523d7/tests/test_fixtures.py#L205, but testing for models to be reloaded might be more difficult/involved).
AFAICS we're using override_settings (https://github.com/pytest-dev/pytest-django/blob/74c271095ef385ca0cc696e725e33ce6a41523d7/pytest_django/fixtures.py#L323-L353), and modify_settings is meant to be used / required for modifying list (https://github.com/django/django/blob/789de6050ae5afed2d8cbf59e12e9a08fa7811e6/django/test/utils.py#L459-L463).
Might be a good idea to switch to modify_settings in general maybe?
@koniiiik
A test case might also be useful with regard to how you used the fixture vs. Django's modify_settings.
Also try replacing the list with a new one instead of appending to see if that works in the first case.
You are absolutely right, it does appear that mutability got the better of me, it is indeed the case that I was modifying the list in place, rather than assigning a new value.
However, with that in mind, I wonder if it would make sense to at least detect the common mutable structures (lists, sets, dicts), and return some sort of proxy object from the settings wrapper that would detect mutations, and trigger the settings override in that case. Opinions?
Sounds good in general.
I forgot about the details,, but wouldn't it work to use modify_settings always?
I don't think modify_settings is applicable, it is just a convenience specialization that simplifies the handling of settings that take lists. In this case, if we want to detect mutations of lists, we already need to do more work than modify_settings does, and it wouldn't add much value anyway.
I'll see if I can cook up some sort of mutation-detecting proxy.
