On Wed, Mar 10, 2010 at 7:51 AM, Brian Rosner <bros...@gmail.com> wrote: > > On Mar 10, 2010, at 7:16 AM, Joan Miller wrote: > >> It's a disaster from the maintenance view point. If it were not so, >> then people would not be proposing to refactor the settings as has >> been made in Pinax, or from multiple posts so many times. > > Like I mentioned in the post you made to the pinax-core-dev mailing list the > problem Pinax is trying to solve is *not* because the settings are written in > Python, but rather loading order and scope. Many projects quickly realize > that running a Django project with a single settings file is nearly > impossible with different environments all interacting with a single code > base. Some projects turn to importing a local_settings.py file which is what > Pinax currently does. This has worked wonderful for us for years. > [snip]
The local_settings.py convention (thanks, Pinax!) has worked well for us in an environment with multiple dev, test, and production server tiers. We solve the DATABASE_PASSWORD= issue by only allowing the DBAs access to local_settings.py on production, and having an svn:ignore rule that prevents anyone from accidentally checking it in to version control. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
