> - 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 -
Since I wrote the original modwsgideploy script I should defend it
here..
1. The location /usr/local/turbogears is used as a reference, you can
place your project anywhere you want except for apache folders, or in
egg inside python installation. Example: /home/turbogears/..../var/
turbogears/ /myapplications/turbogears
2. "So although making some effort to install a special config-
generator script, this does not bother to test the paths it uses. "
Correct. I did not have time to implement the path, I'll see if I can
add that in there.
3. "myapp.wsgi does not do much more than define some paths that could
easily be handled via command-line." Correct. Again. Did not have time
to update it. I'll include that in the next version.
4. "contain implicit assumptions that other installations were done
before, mix names ('myapp' / 'tg2env'), do not mention projects (being
organized _inside_ virtual environments, right?)" I'm not sure what
you mean here? "myapp" is again one of these prefillers, that I think
gets replaced by your project name. The tg2env is a virtualenv
"environment" that you have used for the project. If you have
everything installed systemwide, then I'm not sure how I would detect
that while running the script. What kind of "organization _inside_
virtual environments" do you mean?
So other then the paths not being what they should be is there
anything else that you would like to see?
Maybe add a FAQ page?
If you could email me the "instructions you would like to see on
there.." that would be great.
The whole purpose of the initial development was to get you the
"settings" , update the paths and you are good to go. I guess I can
take it to next level and also update the paths for you.
Thanks,
Lucas
>
> 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.
