have been hitting my head trying to come up with a better way of managing configs. I've worked with quite a lot of other systems, and one thing i like about django is how "simple" it "still" is. this simplicity is a strength, and having a registry makes things.. complicated.
some wild ideas I have been thinking about: a) abstracting configuration to allow config backends. this might be an overkill, but being able to have settings in: a ldap backend, database backend, plain python file, or ini file. you choose. a simple, but powerful api allowing this might be nice. i work with hetergenous systems and being able to easily share certain settings between systems would be eaiser this way. b) easy way to register, override, configurations for apps. a settings.py in an app folder that is "magically" loaded the same way other things are would suffice, but there has to be a way to: -override and prioritize settings, as sometimes you have to override things. -mark defaults, get defaults from other apps, and mark some settings as obligatory. i have a django mingus blog now. when i upgrade mingus, and the many many many apps it has, how do i know without reading all the docs, if there is a new setting that i should set or change? that takes me to: c) configuration migrations and making them easy for users. django core can also benifit from this of course. an easy way to see what configurations have changed, which new ones are available, which ones have been deprecated... d) as mingus kevin points out, we need a conventional way of registering settings that are to be accessible via the admin and do not require an apache restart... damn, battery down, and stil want to write a new post. :D On Feb 26, 7: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 > > i...@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.
