I also work with several fortune 500 clients (though not specifically as a Django consultant, Django is a preferred tool) and the issues your client mentions, Jacob, are very similar to those I deal with.
Some other notes from the concerns of multinational clients: I've had one very long and complex issue with a major client over legacy databases with Composite Primary Keys (and other composite keys more generally), an issue which has also come up in other contexts. One of my smaller clients switched to a strange bastardization of Django and SQLAlchemy because this was an issue. I understand the history of #373 and why it is hard - just for disclosure. A lack of any mechanism for developers to understand what third party apps are reliable, what to avoid, known problems, and so on. This has been a particular complaint since the Django ethos is (rightly) that the core is the core, and other functionality should be packaged into third party apps. App authors do a great job of being really generous with their work, but it is very hard for stuff outside Django's core to get any adoption. The processes involved in adopting a technology can be complex and involve lots of stakeholders, legal and technical due diligence. It is hard enough ticking those boxes to get Django used, it simply isn't worth doing the same for all the other bits. There's a lot of wheel reinventing going on, in my experience. A Django + project might be useful to give the rock-star third-party apps a fighting chance at being used. Pinax is somewhat close, but has a very different purpose and small, agile, company ethos. Startup and Settings are the big killers though, head and shoulders above the previous issues. I've nothing much to add to your comments other than to say that some of the Django deployments I know of are highly heterogeneous, with various servers running different SOA elements, some Django some not. The configuration issues are formidable and involve all kinds of dependencies beyond Django (or even Python). I struggle to see a way that Django could solve those issues, but allowing more flexibility and avoiding tying configuration to an executable module (i.e. settings.py) would be useful. Like the previous posters, I've also had to roll various custom solutions to this problem. Is suspect at least some of the solution will always be custom, though it might be worth making such solutions easier to create. It would also be useful for everyone to scream more loudly that monkey- patching ANYTHING is a very bad idea. Its getting better now (as some of the major things it was solving are solved properly), but it was a woefully overused technique for a while that has meant a lot of deployment pain! That's less about Django and more about evangelizing bad development practice under the guise of Python-Fu. Ian.
-- 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.
