We use something called livesettings in Satchmo. Bruce has published the code on bitbucket so it can be used outside of Satchmo. I believe at one point it was a fork of dbsettings but I may be wrong on that account. Check it out here - http://bitbucket.org/bkroeze/django-livesettings/overview/
Anyway, we have been using extensively in Satchmo and it works for us. I know there was talk on this list a while back about including something more robust in Django. I don't think there's consensus on the best approach yet. Hope this helps, -Chris On Feb 26, 12:53 pm, Jared Forsyth <ja...@jaredforsyth.com> wrote: > If you look at dbsettings (which again, might be dead - i don't know) it > solves a lot of those problems; settings are tied into the "sites" module, > and are presented to the user in a very friendly way. The problem of db > migration is still there, but I can envision an import/export to XML (or > something) functionality where you can get/transfer all settings (or just > for one/a few apps) to another installation. > I've forked my own copy of dbsettings for the project I'm currently working > on (as I said, it was last touched 2007, and out-of-the-box incompatible), > and improving, so I might try to get it polished and more integrated w/ > contrib.admin, and see how it works. > > Jared > > On Fri, Feb 26, 2010 at 11:00 AM, Wes Winham <winha...@gmail.com> wrote: > > I'd love to see a better way of managing settings in the core of > > django. It's a real pain point sometimes for writing and using > > pluggable applications and there's a wide range of ways that > > application developers try to tackle it. Some have basically no > > settings, some plan on users reading the documentation and defining > > all required settings, some have a way of using defaults that can be > > overridden and some have hacked together ways of using the database > > for some settings (I think ReviewBoard does something like this, or > > did). The problem I see is that the *best* way hasn't really bubbled > > to the surface as far as I can tell. Kind of like how database > > migrations are a hard problem, settings management seems kind of > > tricky. > > > Are there things stopping someone from making a really good app for > > managing settings and letting that bubble up to the de facto solution > > like with South? If there are, maybe removing those things would be a > > good target before trying to build the actual solution in contrib. Of > > course, this is probably not the best time for discussing this since > > everyone is trying to get 1.2 out the door, but I'd love to see this > > area improved down the road. > > > My specific pain points: > > * With a given app, it's a crapshoot to find where they define their > > internal settings (some use app/conf/settings.py, some app/conf/ > > default.py, some app/default.py etc) > > * It's hard to tweak settings on deployment for different > > environments. Using a settings_local.py that gets included is a > > workable solution, but it requires you to maintain a monolithic file. > > Something like the conf.d/*.conf debian style of configuration might > > > Pinax is having a similar discussion right now. Maybe something will > > come out of that project that can be applied/adapted to some later > > version of django. That might be a place to apply some development if > > anyone is interested in working towards better settings management. > > >http://groups.google.com/group/pinax-core-dev/browse_thread/thread/d9... > > > -Wes > > > On Feb 26, 2:11 am, Jared Forsyth <ja...@jaredforsyth.com> wrote: > > > I have been looking around for a way of managing user-configurable > > > application settings, and the only solution I have found is dbsettings, > > > which looks like it hasn't been touched in 3 years. > > > So, I would like to know: is dbsettings dead? Or is there a different > > > generally accepted method for having user-friendly app settings? (e.g. > > don't > > > require code modification) > > > > I think that this idea is pretty essential to django's ease of use; there > > > are many applications which have (or should have) settings which only > > effect > > > UI or minor behavioral issues, and shouldn't require a server restart to > > > effect (and imo shouldn't require server write access). It seems that the > > > most viable solution would be to have a database managed settings system > > (in > > > the form of a .contrib module) which would manage this. It also seems > > that > > > having such an infrastructure in place would really encourage app > > > maintainers to have more settings, thereby making the apps even more > > > portable. > > > > Any thoughts? > > > > Thanks, > > > Jared > > > -- > > 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.
