I'm currently working on a solution to this which I call appsettings, and I think it addresses many of the concerns raised here. appsettings loads your module's settings.py in much the same way that contrib.admin loads your admin.py, and you call appsettings.register (can be used as a decorator) to tell appsettings that you want those settings managed. Once registered with appsettings, you access your settings through appsettings.settings.mymodule.xyz. e.g.
import appsettings settings = appsettings.settings.mymodule @ the top of some file. appsettings uses the database to store your configuration, but it also gracefully degrades in the absence of a database -- all settings are still accessible, but are read-only. Take a look at the project on github for a better example/docs: http://github.com/jabapyth/django-appsettings <http://github.com/jabapyth/django-appsettings>Jared On Tue, Mar 2, 2010 at 2:40 PM, Carl Meyer <carl.j.me...@gmail.com> wrote: > On Mar 1, 9:40 am, stuff4ash <ashwo...@gmail.com> wrote: > > I am not necesary advocating magic. But the need for a more robust (or > > lets say, any) configuration management exists for many. > > "Configuration management" is a fuzzy phrase that can mean many things > to many people. I think it'd be more helpful to focus on specific > problems and possible solutions. My critique was specifically of the > suggestion you made for an automatic import of app-level settings.py, > which introduces magical behavior for (AFAICS) no gain. I've certainly > had the need for something like dbsettings or livesettings, though > I've often addressed it with a separate app/model rather than trying > to shoehorn django.conf.settings into a role it wasn't intended for. I > also agree that for projects with many reusable apps (which describes > all of mine), split settings are less headache to manage; I like > Transifex' conf-directory solution and have proposed it for Pinax. > > It's not that the status quo is perfect and no improvement is > possible; just that specific suggestions with concrete use-cases are > more useful than handwavy claims about the need for some major new > subsystem whose purpose and specific features are not clear. > > > I am very familiar with your setup, and its the best one in use I have > > seen. but it has several shortcomings. > > So what shortcomings are relevant to you? > > > one of the few times that I wished django was more plonish. > > Which means what, in this case? > > Carl > > -- > 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<django-developers%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- 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.
