James Bennett wrote: > On 11/1/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: >> View the whole settings file as something you don't just release >> casually and then only post the bits you feel safe doing so. That is >> absolutely normal configuration file practice.
The generated settings.py contains things that are perfectly normal "source code" like things that should be treated as such. How does one only commit part of a file to svn? I think it is worth pointing out the comment that is put in the generated settings.py: # Make this unique, and don't share it with anybody. If we go with your view, that should be removed, because there is nothing special about SECRET_KEY. I think this kinda proves that the original design realized that there were 2 types of settings, but didn't bother to separate them. > > Apologies if I wasn't as clear as I could have been; this is really > what I was getting at by pointing out that settings files contain, > well, settings, and lots of them can be sensitive. My point is to separate them into 2 groups. This separation would solve more than just the "keep secrets secret" problem, but also make it easier to manage the settings that are an integral part of the app. (db type, name, user, password) are all derived from an external source that is going to be different for each installation So it doesn't make sense for them to be rolled into the set of files that is what gets installed. (where "installation" is a copy of the files on a machine for either development, testing or production. Even if multiple developers are working on a single production site, each developer will have their own installation.) Support for the local_settings file is there, I just think it should be changed from an "If it exists" to assuming it exists, and seed it with the values that have been singled out as "secret." > Django's debug > views go to moderate lengths to protect you (by hiding anything with > "PASSWORD" in its name), but not posting full settings files publicly > is really the only solution here. > Um, no. not the _only_ solution. I hardly call that a solution, it is hardly even a workaround. I'm kinda confused by the resistance. Do we really need to start presenting concrete use cases for combined vs separate? Carl K --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
