FWIW - I wasn't completely sure what the problem was you were relating or the solution you were proposing as a means to fix it. I came to this thread a bit late, and was probably overwhelmed by lots of text without reading and understand your first message in the thread well enough. The big replies further down thread don't help your case - they hurt it, because it's now much harder to understand the actual problem and the proposed solution.
Anyway, let me summarise, and you can let me know if I'm off. - The requirement of having all settings defined within the project space (by default) is a poor user experience; because - Good security practise is to define specific settings (SECRET_KEY, various passwords, db connection strings) outside the normal settings.py file so not to commit to source control - Most *nix people are used to putting settings in files such as `/etc/<program>/<program>.conf` - So Django should support such a thing I'll admit that a number of times, including very recently, I've tried to pass `settings=settings/local.py` rather than `settings.local`. As you've also pointed out, there are quite a number of third party apps that deal with settings, and a number of strategies to making production settings available to the program. 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? I think a better solution for managing production settings is probably overdue. I know we've spoken about things like autoloading DJANGO_ environment variables, allowing .ini files, and other various strategies. I kind of like the idea of just reading a python file from the file system. But I also recognise that deployment is so varied that it's going to be nearly impossible to get some kind of consensus on the "one true way". Aiming for a "best default experience" is probably the bar we should be aiming for though. -- 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 [email protected]. To post to this group, send email to [email protected]. 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/eabd54f7-3229-4abf-916c-40fdea2888d3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
