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
> <mailto: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
>     <mailto:django-developers%2bunsubscr...@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
> <mailto: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ález
https://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.

Attachment: pEpkey.asc
Description: application/pgp-keys

Reply via email to