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 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 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 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
> > .
> > For more options, visit this group at
> >http://
