I don't think we should blow this out of proportion. This is *one* person's opinion. As a counterpoint, I also use both Django and TurboGears. I started the Django project first and quite frankly, it will be my last. I absolutely do not like Django. I'd rather have TurboGears' growing pains than Django's convoluted file layout, multitude of silly configuration requirements, etc. Deploying Django, in general, is no easier than deploying TG, and further, requires two *completely* different setups for development and deployment.
The bottom line is this: Django and TG, despite having much in common at a high level, differ greatly at the nuts-and-bolts level, and those differences appeal to (or irritate) different people. Whether or not they recognize that it mostly boils down to personal preference or chalk it up to "beta software" or whatever doesn't change the underlying reality: it's mostly a matter of taste. As far as whether we should be willing to rip out parts of TG if the component's maintainers are unwilling to help resolve issues, I'm against this. All that does is trade the devil we know for one we don't. If it's a real problem, I'd rather see a code fork than a component replacement. Forking means backwards-compatibility while replacement practically guarantees breakage. However, with rare exceptions, it seems that the component developers are more than happy to accept patches and implement fixes to support TG, and forking will generally mean we lose the developer and community support of that component so this should be an absolute last resort. While it's true that RoR and Django don't have to worry much about third-party components, that really means little to end users as the end user *still* has to worry about the (much smaller) RoR and Django teams implementing bug fixes. The bottom line is that unless you are supplying the patch yourself, you will have to wait for someone else to do it. Whether that person is a core maintainer or a component maintainer doesn't seem too relevant. It could have just as easily have been Kevin denying Ian's patch as fumanchu. Then what? Ultimately *someone* has to make decisions and those decisions may not always be popular or even right, but jumping ship whenever it happens will kill the project quicker than anything else I can think of. Finally, I think it's far to early to worry about this stuff. There may be problems with the TG way of doing things and perhaps changes will be required, but only time will tell, and frankly there hasn't been enough time to tell very much at all. Regards, Cliff On Sun, 2006-01-22 at 23:51 -0800, Dan Jacob wrote: > It seems the problems are not so much in TurboGears itself but with the > underlying components - CherryPy in particular recently (see Ian > Bicking's comment at http://blog.ianbicking.org/my-cherrypy-rant.html). > The problem we have is that although we can control the quality of TG > code, we can't control what goes on elsewhere. For example, us poor > benighted Windows users haven't had a functioning Toolbox until > recently, all because of Kid (and that's only fixed in the SVN, not > stable Kid release). I have wanted to add proper localization support > to form validation, but that will have to wait until it's in > FormEncode(for example, it does not seem to support unicode message > strings, which means even lazy_gettext won't work for customizing > messages). > > The question is: how can we guarantee a stable TurboGears platform even > post 1.0 (or for that matter, 2.0) if we cannot guarantee the stability > of the underlying components ? Should we enforce a "comply or die" > attitude to other projects (if you don't fix your issues, we'll go to > Quixote/Cheetah/whatever) ? I don't think that's very workable, and TG > is having a positive "rising tide lifts all boats" effect on other > projects, but still we are often hamstrung by what happens outside of > TG, something Rails and Django don't have to worry about. > > Any ideas ? --
