Most of what you say about the mod wsgi issue is accurate. The docs seem to lack something, but I wouldn't knock turbogears. The few developers that work with Turbogears, and whom I depend on, are fantastic. There is always the time available vs product quality when dealing with opensource products. Turbogears 2.1 is in a transition stage as the developers have joined the pyramid project. From what I have read they are going to bring the turbogears into that project that should produce the best ever web development tool. I just recently went through the same thing you have been through with the mod wsgi deploy. Many hours spent trying to figure it out. It is a week spot, and I am sure the developers will get to that eventually. Since you seem to be a good developer yourself. Why don't you continue your thread on mod wsgi deployment. It would benefit the Turbogears project.
--- On Fri, 1/14/11, bvdb <[email protected]> wrote: From: bvdb <[email protected]> Subject: [TurboGears] Sand in their Joints - TG and mod_wsgi To: "TurboGears" <[email protected]> Date: Friday, January 14, 2011, 7:29 AM - Rant about TurboGears2 - After some years of experience with PHP development (and a bit with RoR and J2EE) I decided it's time for improvement. Python was often mentioned by friends as a superior scripting language, I checked it out and yes: Handling of strings, arrays, functions and objects is much more concise, there is a fresh spirit of keeping things simple and clear. This should be the platform of choice for new projects of mine and something I could recommend honestly to clients, partners and friends. >From all python web frameworks TurboGears appeared as first choice, mainly because of SQLalchemy (having experience with deficiencies of ActiveRecord in RoR). Now, before the first 'hello world' from the apache webserver there was some configuration to do for the wsgi interface. PHP works easily in this aspect, but one can accept a bit more effort for a less popular but superior platform. TurboGears offers a "standard deployment pattern", that sounded well thought-out: http://turbogears.org/2.1/docs/main/Deployment/Standard.html What happened over the next days can be followed in the thread "modwsgi_deploy Helper Script" on this newsgroup. - In short, it's a mess. - The steps described on ../ModWSGI.html don't work as described, contain implicit assumptions that other installations were done before, mix names ('myapp' / 'tg2env'), do not mention projects (being organized _inside_ virtual environments, right?) etc. Then if, after consulting this group, the /apache folder is finally created, the config files therein contain paths to folders never seen before ('/usr/local/turbogears'). So although making some effort to install a special config-generator script, this does not bother to test the paths it uses. Part of the README that is generated in apache/ repeats the very steps that were neccessary to generate it. Then myapp.wsgi does not do much more than define some paths that could easily be handled via command-line. - end of mess-description - The whole process seems to be aimed more at mystifying a python-apache deployment. Ok, one might see this as part of the open source culture, that is not always efficient and functional, like every culture. Then I read the TG home page again: "Rapid web developement framework", and 2.1 claims "Build a database-driven app in minutes!" - but they missed out ".. albeit it might take a couple of days to configure your box for 'Hello world'". That's where "Sand in my Joints", an old anti-hippie punk song (by Wire) came to my mind.. Did someone from TG ever try to convince a developer using another language to switch over to TG? In this case you would have shown him how easy it was to install .. and then you'd notice that you were wrong. Seems no one ever did this test (and TG 2.0 is out since May 2009). I came from PHP to Python because the language is so much more clean, concise and elegant. It seems this was only one part of the python community while the other half cherishes its nerd attitude. Maybe the rest of the package works perfect, but judging from the docs it looks to me there are more blind spots. It's sad because the concept of combining SQLalchemy, ToscaWidgets and Genshi is promising. It seems what the people from Django achieve is not (only) setting the words nicely in the docs but organizing the setup and structures in a clear way, then it actually _works_ nicely, so the docs describing it come out this way. My proposal to the developers is: Quit TurboGears, and contribute your knowledge about SQLalchemy (and maybe Pylons, Genshi, Mako, Toscawidgets etc) to extend Django. This way a python web platform could evolve strong enough to compete against PHP, RoR and J2EE alternatives - not only conceptually but in working systems. / Bernd -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en. -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
