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
Related
It seems the best way to send emails from the django-allauth app asynchronously is to simply install django-celery-email. But the packages warns that
This version requires the following versions:Python 2.7 and Python3.5, Django 1.11, 2.1, and 2.2 Celery 4.0
I've only been using python for several months and never encountered a situation where two python version are needed on a project. And I'm using the official recommendation of pipenv for local development. A quick google shows that it isn't possible to have two python interpreters installed in the virtual environment. Since the plugin seems so popular I wondered how others were setting it up? Apologies if I've missed something major that explains this.
A bonus answer would also take into account that I am using docker and the docker image will install the python packages like this.
RUN pipenv install --system --deploy --ignore-pipfile
Many thanks in advance.
I am pretty sure it is just inaccurate description in the project docs, so you need either python 2.7 or python >=3.5 to be installed
In the end I didn't use django-celery-email. It's easy to send the emails generated by the django-allauth app without this package.
I used these resources -
https://github.com/anymail/django-anymail/issues/79
https://docs.djangoproject.com/en/2.2/topics/email/#defining-a-custom-email-backend
Basically you do this to get it working.
In settings.py define a CustomEmailBackend -
EMAIL_BACKEND = "users.backends.CustomEmailBackend"
In a backend.py file define the backend -
from django.core.mail.backends.base import BaseEmailBackend
from .tasks import async_send_messages
class CustomEmailBackend(BaseEmailBackend):
def send_messages(self, email_messages):
async_send_messages.delay(email_messages)
return len(email_messages)
And this is the task -
from django.core.mail import get_connection
from abstract_base_user.celery import app
#app.task(rety_backoff=True, serializer="pickle")
def async_send_messages(email_messages):
conn = get_connection(backend='anymail.backends.mailgun.EmailBackend')
conn.send_messages(email_messages)
The celery django app should be set up in the standard way as defined at https://docs.celeryproject.org/en/latest/django/first-steps-with-django.html
And the celery settings in the settings.py need include the pickle content type -
CELERY_ACCEPT_CONTENT = ['json', 'pickle']
Obviously you need to include your anytime settings and broker settings too. But this should be enough to get anybody started.
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'm not sure if this is a setting somewhere, but after changing my project from Python 2.7 to Python 3.5 I lost the debugging link in the Run window.
Here is a screen shot running Python 2.7:
Here is the screen shot running Python 3.5:
Am I missing a plugin or is there a setting somewhere for this? I don't want to hunt and peck for the link every time I debug a new project.
I'm running PyCharm version 4.5.3
Update
When app.debug = True it will hide the link, but when set to False, it shows the link (for Python 3 only)
Here is my pip list:
Flask (0.10.1)
Flask-Login (0.3.2)
Flask-SQLAlchemy (2.1)
itsdangerous (0.24)
Jinja2 (2.8)
MarkupSafe (0.23)
pip (7.1.2)
PyMySQL (0.6.7)
setuptools (18.2)
SQLAlchemy (1.0.9)
Werkzeug (0.11.2)
WTForms (2.0.2)
XlsxWriter (0.7.7)
The issue is coming from the version of Werkzeug. In Werkzeug 0.11.02, the project link will not display if app.debug is set to True
Taken from WerkZeug, you directly call run_simple, while passing in the host, port, and app, as a workaround.
from flask import Flask
app = Flask('my_app')
app.debug = True
if __name__ == '__main__':
from werkzeug.serving import run_simple
run_simple('localhost', 4000, app)
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
So I'm trying to use the django 1.1 template engine with the google app engine web app framework, from here. This is on Ubuntu Jaunty, I've made sure that the PYTHONPATH contains the location of Django-1.1.1 yet I'm getting this 'ImportError: No module named django' error when it tries to execute the use_library() line below. Again, could somebody help me? I'm stumped.
import os
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
from google.appengine.dist import use_library
use_library('django', '1.1')
Came up with the following solution:
Get django 1.1 and put it under your project root.
Add an empty file "non_gae_indicator" to your project root folder.
Add django and non_gae_indicator to your app.yaml skip_files element:
skip_files:
- ^(.*/)?app\.yaml
- ^(.*/)?app\.yml
- ^(.*/)?index\.yaml
- ^(.*/)?index\.yml
- ^(.*/)?#.*#
- ^(.*/)?.*~
- ^(.*/)?.*\.py[co]
- ^(.*/)?.*/RCS/.*
- ^(.*/)?\..*
- ^(.*/)?.*\.bak$
- ^django
- ^non_gae_indicator
Now we have a way to tell whether we are running under the GAE-sdk or live - since non_gae_indicator won't be available when we are live.
So in main.py you can do:
if not os.path.exists(os.path.abspath(os.path.dirname(__file__)) + '/non_gae_indicator'):
# GAE
from google.appengine.dist import use_library
use_library('django', '1.1')
else:
# Not GAE - Add our django package to the path
sys.path.insert(0, os.path.abspath(os.path.dirname(__file__)) + '/django')
You should run your local SDK server with the --allow_skipped_files flag (or else the skipped files will appear to not be exist when checking them - the server console gives a warning about it).
#stallarida - The problem is that .96 is shipped as default with the SDK. What I did in the end, which is a dirty hack but works, is to update the version of django in the appengine directory to 1.1. Worked fine, needed a bit of tweaking between dev and production.
Specifically I had to comment out use_library('django', '1.1') when running locally but include it when uploading my app.
I'm sure there's a better solution and I'll work it out when my linux experience improves.