Mark Sapiro writes:
On 2/14/19 11:10 PM, Stephen J. Turnbull wrote:
Torge Riedel writes:
- there is a way to do this now via settings_local.py, but feels a little bit risky if default configuration changes on update of mailman
This should not be true. If it is, we need to fix that. Will check.
It is more or less true [...] the only way settings_local.py can change something like INSTALLED_APPS is to redefine INSTALLED_APPS in it's entirety which leads to the possibility of INSTALLED_APPS changing in settings.py and those changes not being picked up in settings_local.py.
That's a different issue from the one I believe Torge is worried about, which is an update overwriting settings_local.py. But it's not good.
The way around this is to remove the import of settings_local from settings.py and then put
from settings import *
at the beginning of settings_local.py and then point Django at settings_local rather than settings.
I don't understand the ramifications of making this change (presumably Barry or somebody had a reason for the change from Mailman 2's method), but at first glance it looks like a big step in the right direction.
Then you can do things like
try: INSTALLED_APPS.remove('allauth.socialaccount.providers.google') except ValueError: pass
in settings_local.py except there are still issues because, e.g., INSTALLED_APPS is defined as a tuple (immutable) and not a list in settings.py.
Given the concerns of privacy advocates, I would say that it would be better to have a separate
AUTH_PROVIDERS = ['allauth.socialaccount.providers.google', ...]in settings_local.py, and merge that in to INSTALLED_APPS. Of course removing specific providers would be OK too, but I think that this is a place where "deny all / accept what you want" is appropriate.
Steve
-- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN