On 11/1/07, Carl Karsten <[EMAIL PROTECTED]> wrote: > 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?
Why do you need to commit your project's settings file to a publicly-viewable repository? If it's a private repo that only authorized persons have access to, this isn't a problem. > I think this kinda proves that the original design realized that there were 2 > types of settings, but didn't bother to separate them. Yes, there are two types of settings: private settings and public settings. And application-specific settings. Three! Three types of settings: private settings, public settings, and application-specific settings... and locale-specific settings. Four types of settings! > 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. Er... no, it'd make settings more complicated. Right now you configure Django by putting name/value pairs into a single location: the settings module. Your settings module is yours and yours alone, and sharing it with someone you don't trust is a bad idea. Putting project settings files into publicly-viewable places is, quite frankly, not something Django ought to be encouraging. > (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.) If you don't trust your developers to keep a lid on things that ought to be private, you need to get new developers. > I'm kinda confused by the resistance. Do we really need to start presenting > concrete use cases for combined vs separate? You need to present a case for why it's so all-fired important for you to be publicly posting full settings files, because to me that makes no sense whatsoever; the settings file is not part of a Django-based deliverable. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
