3 ms·

It seems django would benefit by brining some of this "in-house", either officially or through blessed third-party tools in the same way that rails does. If de

• njharman 18y ago
  sessions are in contrib, not part of the framework. Some of the testing stuff is "in-house". It's not even close to true that everyone's deployment is (or should be) very similar. It's a bit more arguable that everyone's testing should be similar. But forcing one way is not the Django way and one of the big reasons it is loved.
• jacobian 18y ago
  The thing is that actually very little of this is unique to Django. The types of tools you need to deploy dynamic-language-based web applications don't differ depending what the "P" in LAMP stands for.
  • ashot 18y ago
    That maybe true (Capistrano which you reference was pulled out of 37 signals) but I think my general criticism still stands (+ standardization in and of itself has benefits in that it helps people help each other). The rails community from the beginning has had a more holitstic view of the problem it is solving. The third tab on the rails site is about deployment. There are three performance monitoring companies and 6 different rails specific hosts. Other examples: db schema evolution (migrations) and rake tasks. There is also a litany of useful maintance tools you can find on github. This is not just in reference to code either, its everything else too, including documentation. I like django, I prefer django, but in this one critical area, the last mile, rails does better. And its frustrating because its not a hard problem.