I strongly disagree with this. I've not seen a common standard between companies when it comes to settings in Django and for good reason. Different companies employ different standards and practices when it comes to configuration and security. Enforcing an arbitrary standard - such as a settings file for each env - is too opinionated for me and would often involve extra work on setup to remove this initial way of doing things.
Likewise in my experience ignoring settings files is actually quite rare. Most companies store secrets external to the settings file and prefer to keep their settings in git. Adding a .gitignore with the settings files would actually cause issues on future projects where you aren't expecting this. As mentioned this isn't necessarily to say having multiple settings files or ignoring settings files are bad in an individual project. But that every project has its own way of handling configuration and secrets, so enforcing the standard *you* follow on everyone else - not because it is the best possible way of doing things, but because it is how you do things - is unlikely to be a popular move. Adapting your settings configuration to the way you work is a small amount of work - Django does a good job at the moment of staying unopinionated on this whilst giving you what you need to get going. On the SECRET_KEY. It is true that many people commit their SECRET_KEY into the repo. But in the same way that you often get people committing DB credentials and API keys. It is not a frameworks job to inform you of every security malpractice (although Django does a good job of this already), it is up to the developer to understand what they are doing. Despite this there is extensive documentation on the SECRET_KEY needing to be secret, mentioned both in the settings documentation and the deployment checklist. There is even a comment above this setting explicitly stating that it should be kept secret in production. Assuming Django's startproject command aims to have a fully functioning project from the get go - which means it needs a SECRET_KEY - then I think this is a pretty good compromise as is. - Nick On Fri, Oct 11, 2019 at 12:14 PM Christian González < christian.gonza...@nerdocs.at> wrote: > Hi, may I disagree - I set up projects very often (for testing a package), > and I always feel a bit awkward because of that monolithic settings.py file. > > I can really support Bobby's idea, even if development/staging/production > may be a bit overkill. Having a practical standard which ensures good > practice from the start is a good thing. And OTOH, it won't hurt anyone if > these files are there. > > As there was another discussion earlier about "declarative" settings - > maybe it would be helpful to exclude some of the settings from settings.py > which is code, not declaration. SECRET_KEY could be anywhere by default, it > doesn't have to be in an executable .py file. But this would mean to change > Django's code to read it before or after importing settings.py. > > +1 for a .gitignore file too. > > Christian > Am 10.10.19 um 22:18 schrieb Ehigie Aito: > > Hello Bobby, > I think this should be added to a best practises documentation and not > codified in Django. As I feel that would be overkill. > > On Thu, 10 Oct 2019, 20:41 Bobby Mozumder, <bmozum...@gmail.com> wrote: > >> In particular, they include settings that shouldn’t be stored in a git >> repo such as SECRET_KEY and database passwords. You’ll find these kinds of >> settings in git repos all the time. >> >> Really the default django-admin startproject shouldn’t have a single >> settings.py that people include in their git repos, but instead a python >> settings module, with a base.py, development.py, staging.py, and >> production.py. An __init__.py reads base.py and one of >> development/staging/production based on ENV variables (defaulting to >> development if no ENV variable). >> >> Additionally, startproject should add a .gitignore in the root directory >> to not include development/staging/production settings files. >> >> I get that this might not be absolutely necessary but I think these are >> the kinds of defaults that make practical real-world use more secure, as >> well as standardizing workflow for more advanced production usage. >> >> Is this something agreeable? I can put together a solution if people like >> this. >> >> -bobby >> >> >> -- >> 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 view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/320B70FD-BDC1-445D-B72B-0CD0BA736B88%40gmail.com >> . >> > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CA%2BB1BD6kxbSR_fOwAWxY%3DtjRA30YPcYVt87%2BHguOKyZBOnHnuQ%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CA%2BB1BD6kxbSR_fOwAWxY%3DtjRA30YPcYVt87%2BHguOKyZBOnHnuQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- > Dr. Christian Gonzálezhttps://nerdocs.at > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/bba18cb5-d1d9-79f6-de15-d5186bab1f32%40nerdocs.at > <https://groups.google.com/d/msgid/django-developers/bba18cb5-d1d9-79f6-de15-d5186bab1f32%40nerdocs.at?utm_medium=email&utm_source=footer> > . > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAGuvt93VFf17sStwGLyPf9tSLvuEOYjaKZZ3Y59yEU7BVvVjEQ%40mail.gmail.com.
