I m new to django. I created a web with dajngo,and successfully deployed it in the server
The python app has been successfully setup and virtual environment has been setup.
but while running the web it gives me "Server Error (500)" I don't know whats the problem.
I think error is in "wsgi.py" file but i'm unable to idenify it.
My wsgi file:
import os
from django.core.wsgi import get_wsgi_application
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'karan_web.settings')
application = get_wsgi_application()
my "passenger_wsgi.py" file is:
import imp
import os
import sys
sys.path.insert(0, os.path.dirname(__file__))
wsgi = imp.load_source('wsgi', 'karan_web/wsgi.py')
application = wsgi.application
can someone help me with it;
Sorry for the late answer, I had figured out the as to this just forgot to post it.
As I stated in my question, the actual problem was in passenger_wsgi.py, the django server starts with the wsgi.py and act as the gate way to the Django server.
So whenever a Django project is uploaded on the hosting server, It creates a passenger_wsgi.py file and one default wsgi.py, address of which is provided in passenger_wsgi.py by default.
So we just need to change that address and provide the address of our own wsgi.py in the project
In my case it was
import os
import sys
from karan_web import wsgi
application = wsgi.application
just edit in passenger_wsgi.py the following code.
from karan_web.wsgi import application
You need to check if your code syntax is correct and running properly. If its still doesn't work try to delete and recreate your database in cpanel and check if you have made all necessary migrations, don't forget to restart your python app. If after all these it still doesn't work check if all your files have the correct file permission(766).
Related
Deploying my django website with S3 as storage which runs fine locally to pythonanywhere gives a strange error I can't google a solution for:
"TypeError: a bytes-like object is required, not 'str'"
What I'm doing wrong?
I've tried to put my environment variables out of settings.env (aws keys, secret_key, etc) ad set them directly in my settings.py app. + every suggestion I could find but it's still the same :(
here's my /var/www/username_pythonanywhere_com_wsgi.py:
# +++++++++++ DJANGO +++++++++++
# To use your own Django app use code like this:
import os
import sys
from dotenv import load_dotenv
project_folder = os.path.expanduser('~/portfolio_pa/WEB') # adjust as appropriate
load_dotenv(os.path.join(project_folder, 'settings.env'))
# assuming your Django settings file is at '/home/myusername/mysite/mysite/settings.py'
path = '/home/corebots/portfolio_pa'
if path not in sys.path:
sys.path.insert(0, path)
os.environ['DJANGO_SETTINGS_MODULE'] = 'WEB.settings'
## Uncomment the lines below depending on your Django version
###### then, for Django >=1.5:
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
###### or, for older Django <=1.4
#import django.core.handlers.wsgi
#application = django.core.handlers.wsgi.WSGIHandler()
I'd expect the website to run fine just like it does locally.
Boto library doesn't have a good Python3 support. This particular issue is known in the boto bugtracker: https://github.com/boto/boto/issues/3837
The best way of fixing this is to use boto3 which has decent Python3 support and is a generally most supported AWS SDK for Python.
The reason why it works on your local machine and doesn't work on production is that pythonanywhere setup seems to be using proxy which triggers this incompatible boto code. See the actual calling code: https://github.com/boto/boto/blob/master/boto/connection.py#L747
Your error traceback confirms this.
Unfortunately, I'm not familliar with the django-photologue, but a brief look doesn't suggest that it strongly depends on boto3. Maybe I'm wrong.
I still think that the best way is to go with boto3. As a backup strat you can fork boto with a fix for this issue and install that instead of the official one from PyPI: https://github.com/boto/boto/pull/3699
I have made two settings files, one for local testing and one for production (heroku). Every time I pull and start working locally I need to run the following two commands for it to work:
export DJANGO_SETTINGS_MODULE=
DJANGO_SETTINGS_MODULE=projectName.settings_local
Without doing so I get the error that the local settings module cannot be found. This error appeared after I tried to have both settings files in a settings folder, which I did not get to work so I put them back in the original place. Does anyone have an idea how I can fix this?
In your wsgi.py file setdefault settings file path, in your case local setting file
import os
from django.core.wsgi import get_wsgi_application
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "projectName.settings_local")
application = get_wsgi_application()
You may also need to add in manage.py file
.....
if __name__ == "__main__":
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "projectName.settings_local")
.......
I hope this will help you.
I have been running into this problem for a short while now and simply can't find a solution anywhere. I am using Google App Engine to run a default Python 2.7 app with Django 1.5 (via GAE SDK) created through PyCharm. I can upload the app successfully, but upon visiting the actual page, I get a Server Error. Then, checking the logs in Google App Engine, I see this:
ImportError: <module 'main' from '/base/data/home/apps/s~eloquent-ratio-109701/1.388053784931450315/main.pyc'> has no attribute application
After searching the internet for a while, I was able to find a few posts which address this issue, but attempting them never seemed to solve my problem. For example: This problem was solved by replacing "application" with "app" in the following lines:
application = django.core.handlers.wsgi.WSGIHandler()
util.run_wsgi_app(application)
In fact, I had run into this same issue before and this solution provided a fix for me in the past, however at that time I was running a separate app and it was not through the GAE.
I checked the Django documentation for version 1.5 here, but the code and suggestions there don't seem to conflict with what I currently have in my project.
I read a bit more about this type of problem, and saw another post that suggested checking the app's wsgi.py file to ensure that it is named 'application' or 'app' respectively, so that one could then use that same name throughout the rest of the application. However, upon checking those settings I saw that 'application' was used there too:
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
There's even a line in settings.py which uses the same nomenclature to declare the WSGI application:
WSGI_APPLICATION = 'Chimera.wsgi.application'
I'm really having trouble debugging this. I get the feeling it's really dumb and I just can't see it, but unfortunately I'm not particularly good at this kind of stuff -- I'm still a bit of a novice in this field.
Does anyone have any idea what I could try in an attempt to fix this issue?
UPDATE: I started making line by line changes and testing things, and eventually I found that the GAE log changes depending on the input for the "script" under app.yaml. So if I change the script under "handlers" between "main.app" and "main.application", it adjusts the log output to refer to "app" or "application" respectively. So that line in the app.yaml file tells the app what to look for, but I'm still not seeing why it can't be found. Not sure what else I could change to test it out. I wish I knew a bit more about the actual inner workings so that I could figure out why the app is confused about the attribute. Is it trying to run before it even gets instantiated or something?
Source code below:
main.py
import os, sys
os.environ['DJANGO_SETTINGS_MODULE'] = 'Chimera.settings'
from google.appengine.ext.webapp import util
from django.conf import settings
settings._target = None
import django.core.handlers.wsgi
import django.core.signals
import django.db
import django.dispatch.dispatcher
def main():
application = django.core.handlers.wsgi.WSGIHandler()
util.run_wsgi_app(application)
if __name__ == '__main__':
main()
app.yaml
application: eloquent-ratio-109701
version: 1
runtime: python27
api_version: 1
threadsafe: true
handlers:
- url: /.*
script: main.application
libraries:
- name: django
version: 1.5
wsgi.py
import os
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "Chimera.settings")
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
Full log from GAE:
Traceback (most recent call last):
File "/base/data/home/runtimes/python27/python27_lib/versions/1/google/appengine/runtime/wsgi.py", line 240, in Handle
handler = _config_handle.add_wsgi_middleware(self._LoadHandler())
File "/base/data/home/runtimes/python27/python27_lib/versions/1/google/appengine/runtime/wsgi.py", line 302, in _LoadHandler
raise err
ImportError: <module 'main' from '/base/data/home/apps/s~eloquent-ratio-109701/1.388053784931450315/main.pyc'> has no attribute application
Thanks for helping me out.
In your main.py file (i.e. the main module) application is a variable inside the main() function, not an attribute of the main module. Basically you don't need a main() function.
GAE has some specific support for using Django, I'd strongly suggest going through the Django Support documentation and the Django App example.
Based on the comment made by #DanielRoseman I discovered that declaring the app inside of the main() function caused an issue because the app attribute was then only accessible at the main() function level, as it was a member variable of main() as opposed to a global variable. Although the default application files were structured this way by PyCharm, it seems that it was incorrect. I'm not sure if this is a compatibility issue, but regardless, moving the app declaration outside of the main() function adjusts the scope in a way which allows for other parts of the project to access it, solving my problem.
Thank you #DanielRoseman for the comment.
My current version of django is 1.6.3
And i want to deploy django on my centos server with uwsgi and nginx.
There's a tutorial posted by someone who use 1.3's django that says it should create a file named django_wsgi.py inside my django project. I was wondering if this step could be ignored because i already have wsgi.py in my project at beginning. Are django_wsgi.py and wsgi.py the same thing? Just change the name along with the version upgrade.
#django.py
mport os
import sys
sys.path.append("/opt/www")
os.environ['DJANGO_SETTINGS_MODULE'] = 'your_project.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
#wsgi.py
import os
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "netmag.settings")
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
The project structure generated by startproject changed since 1.3. Before 1.4 release, you had to manually create a wsgi file. Since 1.4, Django automatically creates wsgi.py file in the project root.
Continue using wsgi.py that Django created for you.
A Django 1.6 already has a default WSGI configuration as you can see in your wsgi.py file, nothing else is needed. The instructions you mention are for legacy Django projects.
See https://docs.djangoproject.com/en/1.6/howto/deployment/wsgi/ for more information on the Django WSGI config.
I'm trying to deploy an application with django.
I've put my django_project directory in /home/XXX/websites/YYY.
The web server root is in /srv/http/YYY and it only contains a directory named static and an apache.wsgi file.
The content of apache.wsgi is as follow:
import os, sys
sys.path.append('/home/XXX/websites/YYY')
os.environ['DJANGO_SETTINGS_MODULE'] = 'YYY.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
Whenever I reload apache modules and try to load a page, I got an import error :
ImportError: No module named YYY.settings
I don't understand. Since the settings.py file is in /home/XXX/websites/YYY/YYY/settings.py, why this don't work ?
I've manage to make this work by putting the django project in the web server root directory, but that wasn't the place where I wanted to put it.
Thanks for your help.