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/d9401468ea3c8edf > > -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.
