I tried to upload a simple authentification project to pythonhosted which works and builds on my local machine without errors.
Then i tried to host this one in pythonanywhere.
Nevertheless the main page seems to run but but when i try to use the allauth login feature it crashes:
python3.4 manage.py makemigrations
or
make rebuild
throws the following error:
Here is the code of that project. It is build from this template with little modifications like python3 and some script modification.
Here is my wsgi-file (updated and working)
# +++++++++++ DJANGO +++++++++++
# To use your own django app use code like this:
import os
import sys
#
## assuming your django settings file is at '/home/MaRcMaN/mysite/mysite/settings.py'
path = '/home/MaRcMaN/sqlnoodle_django'
if path not in sys.path:
sys.path.append(path)
#
os.environ['DJANGO_SETTINGS_MODULE'] = 'allauthdemo.settings'
#
## 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()
The stacktrace that you provided (which is almost impossible to read) suggests some possibilities:
that you haven't activated your virtualenv in the Bash shell where you're running your manage.py command
that you haven't installed the correct version of Django into the virtualenv
that you've installed Django into your home directory (not into the virtualenv) and it's a different version to the one that you're using on your local machine
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
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 switching a very large multi-package, multi-app Django (1.4.5) project from using Django's native test runner to py.test (2.3.5). The tests for the lowest level package, web-framework, were discovered and run with no errors after creating a setup.cfg (to manage the py.test options) and a conftest.py (to ignore setup.py). When running py.test (with a setup.cfg and conftest.py) on any higher level package, which all require web-framework, I receive the following error:
ERROR: Could not import settings 'high_level_package.test_settings' (Is it on sys.path?): No module named web_framework.settings
I'm using a virtual environment, and web-framework is in the venv at the following location: ENV/lib/python2.7/site-packages/
I've tried with the venv built in the package's root directory and with it built outside the project path, to no avail. Also, I can import web_framework.settings from the Python interactive command line in the higher level package's root directory.
My current conftest.py is just the following line: collect_ignore = ["setup.py"]
I've tried adding the following lines above it:
import os
import sys
sys.path.append(os.path.dirname(__file__))
I also tried hardcoding in the path to the web-framework package in the above sys.path.append.
Neither worked.
In case it's relevant, my setup.cfg is:
[pytest]
python_files = *test*.py
norecursedirs = node_modules ENV
addopts = --junitxml=python_result.xml, --doctest-modules
Edit:
Forgot to mention the traceback relationship. higher_level_package.test_settings imports higher_level_package.settings, which itself imports web_framework.settings.
in order to have it work you either need to have a develop-install of the worktree, or add . to the PYTHONPATH env var
Change to the folder where your main python website module is located
django-admin runserver --settings=mysite.settings
where mysite was created by
django-admin startproject mysite
I have created a Django 1.3 application on Openshift.
I wanted to upgrade to Django 1.5. So I updated setup.py to install Django 1.5
#!/usr/bin/env python
from setuptools import setup
setup(
name='<Application name>',
version='1.0',
description='',
author='',
author_email='',
url='http://www.python.org/sigs/distutils-sig/',
install_requires=['Django>=1.5'],
)
The server returns http 500.
If setup.py has install_requires=['Django<=1.4'] it works fine.
How can I install Django 1.5 on Openshift?
Update: I can see a github commit where in the install_requires for Django is changed from >=1.3 to <=1.4 for the handling this same issue. But I still cannot figure out what caused that server 500 and how can we install Django 1.5 on openshift
It might come from your code, did you check the backwards incompatibilities mentioned in the release notes (mainly ALLOWED_HOSTS required in your settings.py)
It could also come from the {% url %} tag syntax change, see here.
When i installed Django app on OpenShift, Django version was 1.5.1. I think OpenShift install last version Django, because the condition Django >= 1.4, that is no lower this version.
That is screenshot, when i installed app
I had the same issue : from your screenshot you're using python2.6 ?
Try to use python2.7 with this configurations put on the application file:
#!/usr/bin/env python
import os
import sys
sys.path.append(os.path.join(os.environ['OPENSHIFT_REPO_DIR']))
os.environ['DJANGO_SETTINGS_MODULE'] = 'mywebsite.settings'
virtenv = os.environ['OPENSHIFT_HOMEDIR'] + 'python/virtenv/'
os.environ['PYTHON_EGG_CACHE'] = os.path.join(virtenv, 'lib/python2.7/site-packages')
virtualenv = os.path.join(virtenv, 'bin/activate_this.py')
try:
execfile(virtualenv, dict(__file__=virtualenv))
except IOError:
pass
#
# IMPORTANT: Put any additional includes below this line. If placed above this
# line, it's possible required libraries won't be in your searchable path
#
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
And as refered by #Charles L try to set the settings using allowed host
for various settings(MEDIA_ROOT,TEMPLATE_DIRS) in setting.py it is instructed to give absolute path.I have configured apache with mod_wsgi.I have a wsgi script in the folder named apache that redirects to settings.py.
import os
import sys
path = 'D:/Projects/Dan'
if path not in sys.path:
sys.path.append(path )
os.environ['DJANGO_SETTINGS_MODULE'] = 'Django.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
(don't misunderstand - Django is the name of my project.)
Okay my question is - now that we have imported the path to my project to system path in the wsgi script, isn't it more feasible that I give a relative path in settings.py,since that would make deploying easier.If I am wrong please tell me the standard procedure so that I can set all the path in one file other than 3 files(Apache - httpd.conf, mod_wsgi - django.wsgi, django - settings.py).
Use:
import os
this_directory = os.path.dirname(__file__)
and then:
absolute_directory = os.path.join(this_directory, 'relative.txt')
BTW, calling your project 'Django' is ill advised given that Django package itself is 'django'. You shouldn't rely on differences in case not causing confusion. In short, Python packages/module names should ever differ just by case. Your site project directory is treated as a Python package and thus the problem.