ImproperlyConfigured ENGINE sqlite , Django - django

http://pastebin.com/umBiCJvp here's the traceback and settings. I'm using Django version 1.2.3.

Are you sure that you are running Django 1.2.3. This error message is common when changing to Django 1.2 from 1.1 (since the way database settings are defined has changed).
You can check your version of Django by running python manage.py shell and then:
import django
print django.VERSION
That should give you (1,2,3,'final',0) or something similar. If it's not 1.2.x then thats your problem.

Related

ImportError create_namedtuple_class Django Modeltranslation

I have an error while trying to use django-modeltranslation 0.18.3 in Django 2.2.
Here's the end of the traceback:
[...]
from django.db.models.utils import create_namedtuple_class
ImportError: cannot import name 'create_namedtuple_class' from 'django.db.models.utils' (/home/me/project/.venv/lib/python3.10/site-packages/django/db/models/utils.py)
I can't figure what's wrong with modeltranslations and with django. I recreated a clean venv, nothing works.
Their CHANGELOG does not mention it, but they started using some code relative to django >= 3 in v0.18.3. Version 0.18.2 is the last one that supports django 2.2.

ImportError when using Haystack 2.0.0 with Django 1.5 and Gunicorn WSGI

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.

Openshift: Installing Django 1.5 causes Server 500 error

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

Can't use django management commands because of Import Errors when haystack tries to import multiligualmodel

I'm using django-haystack for searching on my site.
I'm also using django multilingual model for I18n.
I import MultilingualModel in search_indexes.py
I ca run all manangement commands as long as I don't have haystack in the INSTALLED_APPS.
When haystack is in the INSTALLED_APPS and try to run syncdb or migrate (and several other management commands) I'm always getting:
django.core.exceptions.ImproperlyConfigured: ImportError haystack: cannot import name MultilingualModel
This is likely related to the hacks done in haystack.autodiscover(). This behavior is documented here: http://docs.haystacksearch.org/dev/debugging.html#import-errors-on-start-up-mentioning-handle-registrations There is a long discussion in this ticket: https://github.com/toastdriven/django-haystack/issues/84
The long and short if it is that moving haystack.autodiscover() into your urls.py can sometimes resolve this issue. Setting HAYSTACK_ENABLE_REGISTRATIONS = False when running syncdb or migrate has resolved this for me using this snippet in my settings.py:
# FIXME: This is a complete hack to get around circular imports in
# django-haystack and other apps such as django-endless-pagination
SKIP_COMMANDS = ['syncdb', 'migrate', 'schemamigration', 'datamigration']
if any([command in sys.argv for command in SKIP_COMMANDS]):
HAYSTACK_ENABLE_REGISTRATIONS = False
search_indexes.py doesn't get processed unless haystack is in INSTALLED_APPS. The problem is with the import of MultilingualModel in general. Either it's not truly installed in your environment (attempt to import it from a vanilla python shell), or you have the import wrong (it's actually in another module, for example).
Once you can successfully import MultilingualModel from a python shell, you won't have any problems.

Module "django.core.context_processors" does not define a "auth" callable request processor

I have a Django live website , i want to do some kind of maintenance on it but when I downloaded it and tried to open it from my local machine and my debug mode is true
I faced this error:
ImproperlyConfigured at /
Module "django.core.context_processors" does not define a "auth" callable request processor
I'm using Python 2.5
I would be grateful for any help.
It looks like you have upgraded to Django 1.4 or later.
The auth context processor has been moved from django.core.context_processors.auth to django.contrib.auth.context_processors.auth. The move started in Django 1.2, and django.core.context_processors.auth was completely removed in Django 1.4.
I recommend you run the same version of Django on your dev and production environments to prevent errors like this.
When you upgrade to Django 1.4, you need to make the following change to TEMPLATE_CONTEXT_PROCESSORS in your settings file:
# old
TEMPLATE_CONTEXT_PROCESSORS = ("django.core.context_processors.auth",
...
)
# new
TEMPLATE_CONTEXT_PROCESSORS = ("django.contrib.auth.context_processors.auth",
...
)
When migrating, the release notes (1.2, 1.3, 1.4) are useful for catching changes like this.
First check your Django version:
go into your app and run
$./manage.py shell
import django
django.get_version()
In Django >1.4 the previously deprecated-marked setting DATABASE_ENGINE is removed. (This deprecation/removal like tic/toc-cycle is typical for the Django project. )
I am using the following code to fix legacy scripts, which for some reasons have to be kept obsolete...
if not ((hasattr(settings, 'DATABASE_ENGINE') and (settings.DATABASES['default']['ENGINE'] or 'ENGINE' in [x for y in settings.DATABASES.itervalues() for x in y]))):
try:
setattr(settings, 'DATABASE_ENGINE', settings.DATABASES['default']['ENGINE'])
except:
raise Exception('No default ENGINE set in settings.DATABASES!')
Hope this helps.