Opened 10 years ago

Closed 10 years ago

#22928 closed New feature (wontfix)

Provide a option to generate the full settings.py instead of the short, minimal one

Reported by: Guruprasad Owned by: nobody
Component: Uncategorized Version: 1.6
Severity: Normal Keywords: django-admin.py
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

With Django 1.6, the default project template and settings.py were modified to support a minimal configuration that will be helpful for someone getting started with Django. But for a lot of people familiar with Django, it requires a lot of work (and searching in the docs as well if you don't remember all the options) to get started.

While there is the option of using a custom project template while creating the project using the --template flag, providing a way to do that in the stock Django using something like a flag (--full) without having to pick from a huge list of templates available on the internet or at least providing a template from the official Django repository is more friendly and reliable.

Change History (9)

comment:1 by Aymeric Augustin, 10 years ago

If that option is added to copy the 600+ lines of [global_settings.py https://github.com/django/django/blob/master/django/conf/global_settings.py], it should be tidied up first.

Version 0, edited 10 years ago by Aymeric Augustin (next)

comment:2 by Tim Graham, 10 years ago

Resolution: wontfix
Status: newclosed

Thanks for the suggestion, but I don't think this option would be very widely used (and frankly, not something we should encourage). The workaround of manually copying the global_settings.py file seems easy. If you feel strongly about it, please open a discussion on the DevelopersMailingList.

comment:3 by Guruprasad, 10 years ago

Nope, global_settings.py provides way more options than required for a default installation. So copying it is not a workaround. The default settings.py generated as a part of Django before 1.6 release was sufficient and detailed enough unlike the newer settings.py which imho has been oversimplified and may not be suitable for everyone.

comment:4 by Guruprasad, 10 years ago

Resolution: wontfix
Status: closednew

comment:5 by Tim Graham, 10 years ago

Resolution: wontfix
Status: newclosed

I don't think Django should maintain and provide more than one default settings.py. No one will ever be completely happy. I don't think having to read the docs and consciously add settings to a minimal defaults file is a bad thing. If you find yourself doing this a lot, than just maintain your own version that you like. As I said before, if you feel strongly about it, please open a discussion on the DevelopersMailingList as you will get more feedback there, thanks.

comment:6 by Aymeric Augustin, 10 years ago

In any event, bringing back the previous file as is isn't an option.

It was too inconsistent. Why weren't CACHES and TEMPLATE_CONTEXT_PROCESSORS there? Why were STATICFILES_FINDERS and TEMPLATE_LOADERS?

As Tim said, no decision will make everyone happy. One has been made. You'll need stronger arguments to obtain changes.

comment:7 by Guruprasad, 10 years ago

I understand there were some settings which where there which most users wouldn't change like - STATICFILES_FINDERS, TEMPLATE_LOADERS and some others like CACHES and TEMPLATE_CONTEXT_PROCESSORS left out. But the solution here could be to improve the current settings.py to be not so minimal that it is not usable out of the box for most non-beginners or provide a way to generate more detailed settings.py like the one in pre-1.6 Django with the above inconsistencies resolved. I know it is not possible to satisfy everyone and that could be a motivation to move this to "wontfix", but did the changes made to 1.6 satisfy everyone and wasn't it done still done because of a lot of Django developers thinking that it is the right thing to do? I might just be thinking out loud here. But in case you feel that discussing this in the developer's mailing list is the way to go, I will do that as well.

comment:8 by Guruprasad, 10 years ago

Resolution: wontfix
Status: closednew

comment:9 by Tim Graham, 10 years ago

Resolution: wontfix
Status: newclosed

Yes, please use the mailing list. I see other core devs referenced in the commit message for 3f1c7b70537330435e2ec2fca9550f7b7fa4372e where this change was made, so at least a couple other people thought it was a good thing to do.

Note: See TracTickets for help on using tickets.
Back to Top