Everyone's app is different, and so Django is rightly agnostic as to how your settings are stored, and which are loaded.
As for the scope of the problem: dealing with multiple development settings is Section 1, Page 1 of professional programming. It's a solved and trivial problem. This isn't like coding your own ORM or templating language.
It's not trivial. In rails, it's trivial. The framework has knowledge of these separate states of applications. Deploying a serious, hardened service on top of Django is an order of magnitude more complicated than something like Rails.
Schema migrations are yes, a "solved" problem, if by "solved" you mean a third party application that isn't baked into the framework.
Having built a service that hosts Django apps, I can tell you that serious, hardened, services are not as trivial as you think to build with Django. There are countless headaches, and at this point it makes sense to use Rails over Django if you care about making your life easy.
I'm not saying Django isn't without its advantages, but those advantages tend to pale in comparison to some of the problems when you scale past 10 users of a trivial app like a blog.
> Deploying a serious, hardened service on top of Django is an order of magnitude more complicated than something like Rails.
That's funny. How so? I just start gunicorn, point nginx at it, and I'm ready to go. Of course, you could just as easily do it 500 other ways that might make sense to you more.
> Schema migrations are yes, a "solved" problem, if by "solved" you mean a third party application that isn't baked into the framework.
This is absolutely the most absurd thing you've said so far. South handles migrations very well, the code of of excellent quality, and I'm always thrilled to see incremental improvements come down the pipe when they're ready. I don't have to wait for a new Django release.
> Having built a service that hosts Django apps, I can tell you that serious, hardened, services are not as trivial as you think to build with Django. There are countless headaches, and at this point it makes sense to use Rails over Django if you care about making your life easy.
Completely unsupported drivel. We run two separate PCI compliant websites with well over 10k uniques a day per, and have had a pretty easy time of securing both. Django bakes in XSS and a lot of other protection with little to no effort. SQL injection attacks become all but impossible if you don't do anything goofy.
> I'm not saying Django isn't without its advantages, but those advantages tend to pale in comparison to some of the problems when you scale past 10 users of a trivial app like a blog.
Work we do for client spans in the many thousands of users. Django bears the load well, has kept ourselves and our clients safe for over four years now, and lets us develop and deliver quickly.
I'm sure you can do the same for RoR, but why dump on Django when you clearly don't have a firm grasp on it and/or Python?
"a third party application that isn't baked into the framework." In what way is this a bad thing? South has excellent support, code-quality and usage. The only thing that would change by building it into Django would be to tie it's release schedule to that of a much larger code-base.
Why would I want to be forced to use South? There are other migration methods that approach the problem different ways, or perhaps I want to write my own?
Third part != Lower quality. In this case, it means being able to make incremental improvements outside of the Django release schedule. So while Rails bakes it in and forces a release schedule on migrations, South isn't encumbered by this, and is more agile.
Obviously you're going to disagree with me. You gave a talk about this at Djangocon, didn't you?
I'm not saying Django completely sucks -- I'm saying that in certain ways, it gets more and more complicated, rather than staying simple as you grow or build projects that need to scale.
Disqus is a clear outlier here, so I could be wrong. It just seems that every time I encounter a problem, someone says "It's easy to hack Django to fix this!" and that's the problem. I don't want to hack it -- I want it to work like that in the first place.
Pylons was AWESOME. I need to give Pyramid a try, I've heard great things.
I'm also certainly not badmouthing the contributors, I'm criticizing the framework's design. Which is something that's really hard to change after years of momentum.
The difference between my keynote and your comment is that I gave suggestions on how to fix the things I saw problems with, and I didn't belittle people by implicitly trivializing their apps in suggesting they only have "10 users".
Development and production settings is trivial with Django, so if you had problems with this, then I don't know what more I can say.
Lastly, there is a world of difference between developing a Django app and developing an company that deploys Django apps. There are some design decisions that were made in the beginning that makes the former easier and the latter more difficult. I think you're conflating the two.
If I have to use third party middleware or apps to deal with inadequacies of a framework, that's a pretty big alarm that something bigger is wrong.
I saw bottle just this past week on HN and I'm itching to give it a shot.