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
import sys
INSTALLED_APPS += ('django_nose', )
NOSE_ARGS = (
'--logging-clear-handlers', # Clear all other logging handlers
'--nocapture', # Don't capture stdout
'--nologcapture', # Disable logging capture plugin
# '--processes=-1', # Automatically set to the number of cores
)
if sys.stdout.isatty():
NOSE_ARGS += ('--with-progressive', ) # See https://github.com/erikrose/nose-progressive
TEST_RUNNER = 'django_nose.NoseTestSuiteRunner' # Default: django.test.runner.DiscoverRunner
nose.py code is NOT imported in the project code. I knew I had to look at ixc-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 like CELERYBEAT_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 of the-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.
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.pynose.pycode is NOT imported in the project code. I knew I had to look atixc-django-dockerbut 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_SCHEDULEshow 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.pythan 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.