> I've never understood the desire for more magical behavior here. My > apps have a settings.py that imports django.conf.settings and provides > any necessary defaults for unset settings; the rest of my app imports > from there. Works great, easy to look and see what settings my app > consumes and what defaults they have. I don't see what advantages a > more complex system would provide. Example > here:http://bitbucket.org/carljm/django-adminfiles/src/tip/adminfiles/sett...
I am not necesary advocating magic. But the need for a more robust (or lets say, any) configuration management exists for many. I think the problem stems when you when apps become more modular, and your projects more complex, people start to ask for a more robust configuration. I am talking about +30~50 apps. that's why you have stuff like buildout, registries, etc... I am very familiar with your setup, and its the best one in use I have seen. but it has several shortcomings. I think django should stay "lean" and flexible, and should avoid bloat, that doesn't mean we shouldn't be discussing ways to improve it, and as django grows it will face the inevitable challenge of catering different uses. mingus creator discusses shortly the the config problem in django advent:http://djangoadvent.com/1.2/everything-i-hate-about-mingus/ at work I use plone as a base and django for very lean project/apps, privately using django for a lot of lean stuff. but django-mingus is the first project that I have used the leverages the most reusable apps (havent used pinax nor satchmo yet). And I am working on making it a resuable app itself. one of the few times that I wished django was more plonish. -- 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.
