James Bennett wrote: > 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?
Same reason I need to put urls.py and all the other files that are part of what makes things work. >> 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! > You are correct, but those cases are not addressed in the generated settings.py. like has been said, it is .py, so the developer can do what they want. I am just trying to make the starting point 'better' than it currently is, and it currently does address SECRET_KEY and local_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. Actually, it would make it simpler. currently there is a comment and a try/except block of code. making the 2nd file standard would remove the need for both. > Right now you configure > Django by putting name/value pairs into a single location: the > settings module. Maybe you do, but I use the local_settings file too. > 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. If that was true, then there doesn't need to be # ...and don't share it with anybody. and # this will attempt to load a file called local_settings.py ... They were put in deliberately, so I am pretty sure my thoughts are more inline with the original design than your "whole thing is private" thoughts. > >> (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. > You are missing my point there - it isn't a trust thing, it is a work flow thing. consider how often each of these cases happen: case 1: all developers are using a common db, user, password. one of those gets changed (like the pw changes every month), so one developer makes the change in settings.py, commits it, and the rest of the developers can pull down the change. case 2: not all developers use the same db, user, password, so if one changes settings.py, it will break other developers db connection. Case 1 will happen, but I think it will happen enough that it should be accounted for in the generated settings.py. >> 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. I agree: you don't need to publicly post *full* settings files. exactly my point. Do I need to elaborate? 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 -~----------~----~----~----~------~----~------~--~---
