I am using ubuntu and I have installed django from the Ubuntu Software Center. For some projects I want to use the django cloned from the trunk instead of the default one. How can i do that ? Do I need to unistall the one provided by ubuntu?
Create a virtualenv for your django (with --no-site-packages) and activate it. Then install everything you need inside it.
No, simply make sure that the one you want to use shows up in an earlier directory in sys.path.
if wsgi in use
then set the path to the desired django installation in the django.wsgi file. eg
import os
import sys
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
sys.path[:0] = ['/path/to/django/version/','/path/to/project/']
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
If modpython then set the path in the apache configuration file
PythonPath "['/path/to/django/version','/path/to/project'] + sys.path"
The docs might help:
http://docs.djangoproject.com/en/dev/howto/deployment/modpython/
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 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
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 use django-haystack 2.0.0 to index my site, and it has been working great until I upgraded to Django 1.5 and started using the WSGI interface. If I just use the django_gunicorn command it works great, but the Django documentation "highly recommends" I use the gunicorn command.
When I start my site with the gunicorn command, Haystack throws the following error on any page load:
ImportError: cannot import name signals
I have no problems importing signals from the Django or Python shells. I use virtualenv and install all packages locally inside that environment. My wsgi.py file looks just like the default one in the django admin, except that I add the local path to the python path as such:
path = os.sep.join(os.path.abspath(__file__).split(os.sep)[:-2])
if path not in sys.path:
sys.path.append(path)`
Any help you could provide would be very appreciated, thank you!
I don't use gunicorn, but I had the same problem when I used the HAYSTACK_SIGNAL_PROCESSOR setting to point to a custom class that I wrote. That class imported one of my models, which eventually propagated up the import chain, to import my settings module, thus causing a circular import.
When using a setting such as HAYSTACK_SIGNAL_PROCESSOR that points to a class, make sure that class standsalone, and doesn't import either directly or indirectly the Django settings file.
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.