Open FrancoisConstant opened 1 year ago
@mrmachine there is a comment here from you https://github.com/ixc/ixc-django-docker/issues/10#issuecomment-366593592
and I'm not convinced that where I ended up was any better...
Can you expend on this? I know your message was from 5 years ago :D
Any second thoughts? Any change in ixc-django-docker which would make this easier now?
EXAMPLE OF MAGICAL SETTING (just an example):
This morning, on a project, I had to add this to my settings to get the tests running locally:
NOSE_ARGS = [a for a in NOSE_ARGS if a not in ('--with-progressive',)]
That was to remove a setting that was NOT in my codebase.
It comes from ixc-django-docker:
the-project/src/ixc-django-docker/ixc_django_docker/settings/nose.py
nose.py
code is NOT imported in the project code. I knew I had to look atixc-django-docker
but it's not obvious and it takes extra time to figure out what the setting is. I don't remember all the particular cases but finding or searching settings is always a pain when it shouldn't be. Also with the magic, you cannot "navigate" the file properly in an IDE - i.e. settinsg likeCELERYBEAT_SCHEDULE
show up as errors in the IDE (not imported) and you cannot click on it to reveal its default content.This situation often happens: something doesn't work or behave the way we expect because of a setting which isn't in our codebase (so we miss it). It's not even imported in
the-project/settings.py
. It's magically added in.I would rather have
from ixc_django_docker.settings.nose import *
at the top ofthe-project/settings/settings.py
than the currently magical behaviour.Alternatively (I think @jmurty suggested that), having no import and a just big setting file would work well too.
@mrmachine @Aramgutang @aweakley @jacobcolyvan @joaquinpunales1992 @rushil02 @tpmac1990 Does removing magic from settings import make sense to everybody? Is that fairly easy to achieve? I'm happy to pair up with someone to get this right.