I implemented this based upon the code snippet I showed in my first reply. Anyone who wishes to use DJANGO_SETTINGS_FILE can now pip install django-settings-file and follow its setup instructions: https://pypi.python.org/pypi/django-settings-file
I've added some caveats I thought of during development in the project README. I'll copy those here that are relevant to the idea in itself, not just my implementation: - If the Python file defined by DJANGO_SETTINGS_FILE tries to do any imports, the directory the file is in will not be on PYTHONPATH, so the author of the settings file might get some surprises. - Additionally, you might experience other problems from loading a file whilst it’s not on PYTHONPATH. - If you want your settings file to extend another one, it will probably find it easiest to import the base one from a location on PYTHONPATH, otherwise it too will have to do use the same import ‘hacks’ to load the default settings. - File paths are not portable between operating systems, so you may need logic to support both Unix and Windows at once. - - File paths are not portable between .py and .pyc files. In most cases this means a .pyc file will not be used for settings since it can't be guaranteed to be there, slightly slowing down import time. I think Django core should still stick with DJANGO_SETTINGS_MODULE. Python's import machinery does a lot for us. On Monday, April 10, 2017 at 6:12:02 AM UTC+1, Luke Plant wrote: > > > > On 09/04/17 16:16, Josh Smeaton wrote: > > > So I think there are a few questions to go over. > > 1. What are the more successful strategies that work in the wild? (files > in /etc/, PYTHONPATH, env vars, local_settings.py) > 2. Are any of the above clearly superior? > 3. Is this a serious problem that people are having? > 4. If yes, does it need to be solved in core? > > > To put a word in on number 2 regarding environment variables, we should > take into account articles like: > > > https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/ > > > The argument for solving in core would be if there are security issues we > can genuinely fix by putting something in core rather than allowing custom > mechanisms, and if that mechanism will really work in most cases. We also > need to consider shared hosting where /etc/ is not an option. > > Luke > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e569dfb9-5809-423b-9f27-1208af9b1f93%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
