I took a closer look at your original messages since the problem is more than just FastCGI. But I'm not sure we'll be able to solve your problem definitively for reasons described below.
On Tue, Jan 26, 2010 at 11:34 AM, PF4Pylons <[email protected]> wrote: > Hi all > > I am beginner with pylons and Python and I am trying to move an > Appweblication from a server to a shared host environment. The > Appweblication was developed by somebody else, I am not programmer and > I am trying to learn what it takes to just do the move. Well first, what's an Appweblication? Is this something specific to GoDaddy or your previous server? Or do you just mean a web application. > Here is what I am running: > > -Python 2.5 installed in a virutal environment because I needed to add > some more modules that were not allowed by the hosting company. They > also run a older version. The provider is Godaddy so if anyone managed > to install Pylons Appweblication there I would be glad to hear about > their experiences. >I can't understand why when I run the aplication using paster via command line everythig is fine but when I try to start it as CGI there are some dependencies missing. I'm pasting in parts of two messages here. It's possible that the webserver is not running the Python in your virtualenv but the system Python. In that case, it won't have access to the modules in your virtualenv. If you can get a simple Pylons application running in debug mode, you can insert "raise RuntimeError" and look through the variables in the interactive traceback. If that doesn't work, just make a simple CGI script that prints the Python path: import sys, pprint print "Content-type: text/plain" print print sys.executable pprint.pprint(sys.path) import somemodule print somemodule That'll show which Python is running and where it can load modules from. Printing a module object shows which directory it was imported from. > Python is the ActivePerl version because this version comes with all > the modules that I needed included. I take it you meant ActivePython. > I needed sqlite2 but ActivePerl > has sqlite3 I hope that is good. I've always used 3. I haven't heard of any compatibility problems between the versions. > I haven't reach the point to run the > Appweblication > > -Pylons 0.9.6.2 So it's a pretty old application, more than a year old I guess. > -I had to remove Routes Routes-1.10.3-py2.5.egg and to install > routes==1.9 Routes has some new defaults, so it's possible these are incompatible with your older application. Older apps often depend on minimization and implicit defaults. (Not that that means anything to you, but it would be the first place to look if you wanted to upgrade the app.) > /<myhomedir>html/Others/PVE/lib/python2.5/site-packages/Pylons-0.9.6.2- > py2.5.egg/pylons/middleware.py:11: DeprecationWarning: The > webhelpers.rails package is deprecated. > - Please begin migrating to the new helpers in webhelpers.html, > webhelpers.text, webhelpers.number, etc. > - Import url_for() directly from routes, and redirect_to() from > pylons.controllers.util (if using Pylons) or from routes. > - All Javascript support has been deprecated. You can write > link_to_remote() > yourself or use one of the third-party Javascript libraries. > from webhelpers.rails.asset_tag import javascript_path These are due to version changes in WebHelpers. You can ignore these, or downgrade WebHelpers until they disappear. I think the rails warning was added in version 0.6. WebHelpers 0.3.4 is still on PyPI but it's hidden so you'll have to go to the exact URL: http://pypi.python.org/pypi/WebHelpers/0.3.4 . Otherwise you can use 0.6.4 and ignore the messages. Don't use any of the WebHelpers 1.0 betas, because they don't have the deprecated code. > File "/home/resolve/Lib/code/Appweb/Appweb/config/middleware.py", > line 34, in make_Appweb > File "/home/resolve/Lib/code/Appweb/Appweb/config/environment.py", > line 27, in load_environment > File "/home/resolve/Lib/code/Appweb/Appweb/lib/Appweb_globals.py", > line 17, in __init__ > ImportError: No module named fonts I don't think there's a 'fonts' module among Pylons' dependencies, so it must be something the application is using. I'm also surprised at those 'make_appweb' and 'Appweb_globals.py' names, and 'Appweb/Appweb' (instead of 'Appweb/appweb'). Current Pylons applications have a 'make_app' function and a 'myapp/lib/app_globals.py' file. Perhaps 0.9.6 was more different than I thought, or perhaps the traceback is corrupted. > [Tue Jan 26 12:27:15 2010] [error] [client 199.43.172.9] Premature end > of script headers: /var/chroot/<myhomedir>html/cgi/test.cgi This always happens when a CGI script aborts without outputing a Content-type header. I don't know if any of us use GoDaddy or have tried to run a Pylons application on it. I had a GoDaddy domain years ago but have not done webhosting on it. So I don't know if we can offer any specific advice about your import errors. I'm also puzzled by your insistance on using GoDaddy. If it's a business application that has to be running, the company should be looking for an adequate webhost that has the software you need, not the cheapest webhost. If it's a personal site or it's for a nonprofit with no budget or you have a contractual obligation with GoDaddy, OK. But you can lease a virtual server for $20/month from Linode, tummy.com, Rackspace, or several other places. Or a "cloud" server from Amazon or Rackspace, though that may cost a bit more to keep one running continuously. Then you'll get a current Linux distribution with the latest software, and total freedom to configure Apache however you want. -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en.
