Some people use just one settings file for their project. A good alternative is writing modules, replacing the one settings file with a directory with configurations for each specific need:
...
|
settings
|
|-base.py
|-local.py
|-local_alex.py
|-production.py
|-staging.py
|-test.py
I guess it's normal to have one single settings file for production.
But what happens if I have more staging instances/versions?
Let's suppose I have a postgresql DB for each staging instance/environment. Is it ok to have more staging files? Or should I treat the differences between staging versions in another way?
So I could wether have two settings file, one for each staging version or use the same settings file but specify these differences in another way.
What is the recommended approach?
DjangoTwoScoops recommends having more local.py settings files, but no one mentions about several staging files.
Example, I have the production, local and test files. But two staging versions, each with an URL and different database.
DATABASES = {
'default': {
...
'NAME': 'dbname1',
'USER': 'username1',
...
}
}
and the second one:
DATABASES = {
'default': {
...
'NAME': 'dbname2',
'USER': 'username2',
...
}
}
It's a good idea to use a base settings file to define common settings which can be overridden by environment variables. So your database settings might look like;
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'HOST': os.environ.get('DATABASE_HOST', 'localhost'),
'PORT': os.environ.get('DATABASE_PORT', '3306'),
'USER': os.environ.get('DATABASE_USER', 'root'),
'PASSWORD': os.environ.get('DATABASE_PASSWORD', ''),
'NAME': os.environ.get('DATABASE_NAME'),
},
}
The example you've provided is good practice, but I'd avoid specific files for a person, or if you can, specific local settings. Instead look to have environment variables to account for what would otherwise get it's own settings file. That way, it's less code to maintain & easily configured on each server/environment. Each environment your project runs in would define DJANGO_SETTINGS_MODULE in the environment variables to tell django which settings to use.
Use environment specific settings files to inherit the base and then include things like logging and error notifications, if you subscribe to a service like Sentry, which you wouldn't want to be integrated outside of production. So production.py might include additional security settings which you'd want when running in that environment;
DEBUG = False
CSRF_COOKIE_SECURE = True
SESSION_COOKIE_SECURE = True
SECURE_BROWSER_XSS_FILTER = True
SECURE_CONTENT_TYPE_NOSNIFF = True
SECURE_HSTS_SECONDS = 31536000
SECURE_HSTS_INCLUDE_SUBDOMAINS = False
And if you find that the local settings approach works for you, exclude them from git so that a specific person's settings aren't checked in and if they've got a local database server, they don't need to worry that there password is forever in version control etc.
If you want to have those files tracked via git you don't really have a choice - you put all common settings in one tracked file (settings.py), connection settings for each environment in a different file (settings_prod.py) and then access keys in one untracked (settings_local.py).
But honestly it's not that difficult to make connections work the same way in all environments, so you can put those settings in common file and then only swap untracked file with keys for oauth, etc.
I am trying to set up multiple setting files (development, production, ..) that include some base settings. Cannot succeed though. When I try to run ./manage.py runserver I am getting the following error:
(cb)clime#den /srv/www/cb $ ./manage.py runserver
ImproperlyConfigured: The SECRET_KEY setting must not be empty.
Here is my settings module:
(cb)clime#den /srv/www/cb/cb/settings $ ll
total 24
-rw-rw-r--. 1 clime clime 8230 Oct 2 02:56 base.py
-rw-rw-r--. 1 clime clime 489 Oct 2 03:09 development.py
-rw-rw-r--. 1 clime clime 24 Oct 2 02:34 __init__.py
-rw-rw-r--. 1 clime clime 471 Oct 2 02:51 production.py
Base settings (contain SECRET_KEY):
(cb)clime#den /srv/www/cb/cb/settings $ cat base.py:
# Django base settings for cb project.
import django.conf.global_settings as defaults
DEBUG = False
TEMPLATE_DEBUG = False
INTERNAL_IPS = ('127.0.0.1',)
ADMINS = (
('clime', 'clime7#gmail.com'),
)
MANAGERS = ADMINS
DATABASES = {
'default': {
#'ENGINE': 'django.db.backends.postgresql_psycopg2', # Add 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'.
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'cwu', # Or path to database file if using sqlite3.
'USER': 'clime', # Not used with sqlite3.
'PASSWORD': '', # Not used with sqlite3.
'HOST': '', # Set to empty string for localhost. Not used with sqlite3.
'PORT': '', # Set to empty string for default. Not used with sqlite3.
}
}
# Local time zone for this installation. Choices can be found here:
# http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
# although not all choices may be available on all operating systems.
# In a Windows environment this must be set to your system time zone.
TIME_ZONE = 'Europe/Prague'
# Language code for this installation. All choices can be found here:
# http://www.i18nguy.com/unicode/language-identifiers.html
LANGUAGE_CODE = 'en-us'
SITE_ID = 1
# If you set this to False, Django will make some optimizations so as not
# to load the internationalization machinery.
USE_I18N = False
# If you set this to False, Django will not format dates, numbers and
# calendars according to the current locale.
USE_L10N = False # TODO: make this true and accustom date time input
DATE_INPUT_FORMATS = defaults.DATE_INPUT_FORMATS + ('%d %b %y', '%d %b, %y') # + ('25 Oct 13', '25 Oct, 13')
# If you set this to False, Django will not use timezone-aware datetimes.
USE_TZ = True
# Absolute filesystem path to the directory that will hold user-uploaded files.
# Example: "/home/media/media.lawrence.com/media/"
MEDIA_ROOT = '/srv/www/cb/media'
# URL that handles the media served from MEDIA_ROOT. Make sure to use a
# trailing slash.
# Examples: "http://media.lawrence.com/media/", "http://example.com/media/"
MEDIA_URL = '/media/'
# Absolute path to the directory static files should be collected to.
# Don't put anything in this directory yourself; store your static files
# in apps' "static/" subdirectories and in STATICFILES_DIRS.
# Example: "/home/media/media.lawrence.com/static/"
STATIC_ROOT = '/srv/www/cb/static'
# URL prefix for static files.
# Example: "http://media.lawrence.com/static/"
STATIC_URL = '/static/'
# Additional locations of static files
STATICFILES_DIRS = (
# Put strings here, like "/home/html/static" or "C:/www/django/static".
# Always use forward slashes, even on Windows.
# Don't forget to use absolute paths, not relative paths.
)
# List of finder classes that know how to find static files in
# various locations.
STATICFILES_FINDERS = (
'django.contrib.staticfiles.finders.FileSystemFinder',
'django.contrib.staticfiles.finders.AppDirectoriesFinder',
# 'django.contrib.staticfiles.finders.DefaultStorageFinder',
)
# Make this unique, and don't share it with anybody.
SECRET_KEY = '8lu*6g0lg)9z!ba+a$ehk)xt)x%rxgb$i1&022shmi1jcgihb*'
# List of callables that know how to import templates from various sources.
TEMPLATE_LOADERS = (
'django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader',
# 'django.template.loaders.eggs.Loader',
)
TEMPLATE_CONTEXT_PROCESSORS = (
'django.contrib.auth.context_processors.auth',
'django.core.context_processors.request',
'django.core.context_processors.debug',
'django.core.context_processors.i18n',
'django.core.context_processors.media',
'django.core.context_processors.static',
'django.core.context_processors.tz',
'django.contrib.messages.context_processors.messages',
'web.context.inbox',
'web.context.base',
'web.context.main_search',
'web.context.enums',
)
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'watson.middleware.SearchContextMiddleware',
'debug_toolbar.middleware.DebugToolbarMiddleware',
'middleware.UserMemberMiddleware',
'middleware.ProfilerMiddleware',
'middleware.VaryOnAcceptMiddleware',
# Uncomment the next line for simple clickjacking protection:
# 'django.middleware.clickjacking.XFrameOptionsMiddleware',
)
ROOT_URLCONF = 'cb.urls'
# Python dotted path to the WSGI application used by Django's runserver.
WSGI_APPLICATION = 'cb.wsgi.application'
TEMPLATE_DIRS = (
# Put strings here, like "/home/html/django_templates" or "C:/www/django/templates".
# Always use forward slashes, even on Windows.
# Don't forget to use absolute paths, not relative paths.
'/srv/www/cb/web/templates',
'/srv/www/cb/templates',
)
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.staticfiles',
'south',
'grappelli', # must be before admin
'django.contrib.admin',
'django.contrib.admindocs',
'endless_pagination',
'debug_toolbar',
'djangoratings',
'watson',
'web',
)
AUTH_USER_MODEL = 'web.User'
# A sample logging configuration. The only tangible logging
# performed by this configuration is to send an email to
# the site admins on every HTTP 500 error when DEBUG=False.
# See http://docs.djangoproject.com/en/dev/topics/logging for
# more details on how to customize your logging configuration.
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'filters': {
'require_debug_false': {
'()': 'django.utils.log.RequireDebugFalse'
}
},
'formatters': {
'standard': {
'format' : "[%(asctime)s] %(levelname)s [%(name)s:%(lineno)s] %(message)s",
'datefmt' : "%d/%b/%Y %H:%M:%S"
},
},
'handlers': {
'mail_admins': {
'level': 'ERROR',
'filters': ['require_debug_false'],
'class': 'django.utils.log.AdminEmailHandler'
},
'null': {
'level':'DEBUG',
'class':'django.utils.log.NullHandler',
},
'logfile': {
'level':'DEBUG',
'class':'logging.handlers.RotatingFileHandler',
'filename': "/srv/www/cb/logs/application.log",
'maxBytes': 50000,
'backupCount': 2,
'formatter': 'standard',
},
'console':{
'level':'INFO',
'class':'logging.StreamHandler',
'formatter': 'standard'
},
},
'loggers': {
'django.request': {
'handlers': ['mail_admins'],
'level': 'ERROR',
'propagate': True,
},
'django': {
'handlers':['console'],
'propagate': True,
'level':'WARN',
},
'django.db.backends': {
'handlers': ['console'],
'level': 'DEBUG',
'propagate': False,
},
'web': {
'handlers': ['console', 'logfile'],
'level': 'DEBUG',
},
},
}
LOGIN_URL = 'login'
LOGOUT_URL = 'logout'
#ENDLESS_PAGINATION_LOADING = """
# <img src="/static/web/img/preloader.gif" alt="loading" style="margin:auto"/>
#"""
ENDLESS_PAGINATION_LOADING = """
<div class="spinner small" style="margin:auto">
<div class="block_1 spinner_block small"></div>
<div class="block_2 spinner_block small"></div>
<div class="block_3 spinner_block small"></div>
</div>
"""
DEBUG_TOOLBAR_CONFIG = {
'INTERCEPT_REDIRECTS': False,
}
import django.template.loader
django.template.loader.add_to_builtins('web.templatetags.cb_tags')
django.template.loader.add_to_builtins('web.templatetags.tag_library')
WATSON_POSTGRESQL_SEARCH_CONFIG = 'public.english_nostop'
One of the setting files:
(cb)clime#den /srv/www/cb/cb/settings $ cat development.py
from base import *
DEBUG = True
TEMPLATE_DEBUG = True
ALLOWED_HOSTS = ['127.0.0.1', '31.31.78.149']
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'cwu',
'USER': 'clime',
'PASSWORD': '',
'HOST': '',
'PORT': '',
}
}
MEDIA_ROOT = '/srv/www/cb/media/'
STATIC_ROOT = '/srv/www/cb/static/'
TEMPLATE_DIRS = (
'/srv/www/cb/web/templates',
'/srv/www/cb/templates',
)
Code in manage.py:
(cb)clime#den /srv/www/cb $ cat manage.py
#!/usr/bin/env python
import os
import sys
if __name__ == "__main__":
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "cb.settings.development")
from django.core.management import execute_from_command_line
execute_from_command_line(sys.argv)
If I add from base import * into /srv/www/cb/cb/settings/__init__.py (which is otherwise empty), it magically starts to work but I don't understand why. Anyone could explain to me what's going on here? It must be some python module magic.
EDIT: Everything also starts to work if I remove this line from base.py
django.template.loader.add_to_builtins('web.templatetags.cb_tags')
If I remove this line from web.templatetags.cb_tags, it also starts to work:
from endless_pagination.templatetags import endless
I guess it is because, in the end, it leads to
from django.conf import settings
PER_PAGE = getattr(settings, 'ENDLESS_PAGINATION_PER_PAGE', 10)
So it creates some weird circular stuff and game over.
I had the same error and it turned out to be a circular dependency between a module or class loaded by the settings and the settings module itself. In my case it was a middleware class which was named in the settings which itself tried to load the settings.
I ran into the same problem after restructuring the settings as per the instructions from Daniel Greenfield's book Two scoops of Django.
I resolved the issue by setting
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "project_name.settings.local")
in manage.py and wsgi.py.
Update:
In the above solution, local is the file name (settings/local.py) inside my settings folder, which holds the settings for my local environment.
Another way to resolve this issue is to keep all your common settings inside settings/base.py and then create 3 separate settings files for your production, staging and dev environments.
Your settings folder will look like:
settings/
__init__.py
base.py
local.py
prod.py
stage.py
and keep the following code in your settings/__init__.py
from .base import *
env_name = os.getenv('ENV_NAME', 'local')
if env_name == 'prod':
from .prod import *
elif env_name == 'stage':
from .stage import *
else:
from .local import *
I had the same error with python manage.py runserver.
For me, it turned out that it was because of a stale compiled binary (.pyc) file. After deleting all such files in my project, server started running again. :)
So if you get this error, out of nowhere, i.e without making any change seemingly-related to django-settings, this could be a good first measure.
Remove .pyc files
Ubuntu terminal command for deleting .pyc :
find . -name "*.pyc" -exec rm -rf {} \;
I have got same error when I did python manage.py runserver. It was because .pyc file. I deleted .pyc file from project directory then it was working.
I hadn't specified the settings file:
python manage.py runserver --settings=my_project.settings.develop
I had the same problem with Celery. My setting.py before:
SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY')
after:
SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY', <YOUR developing key>)
If the environment variables are not defined then: SECRET_KEY = YOUR developing key
It starts working because on the base.py you have all information needed in a basic settings file. You need the line:
SECRET_KEY = '8lu*6g0lg)9z!ba+a$ehk)xt)x%rxgb$i1&022shmi1jcgihb*'
So it works and when you do from base import *, it imports SECRET_KEY into your development.py.
You should always import basic settings before doing any custom settings.
EDIT:
Also, when django imports development from your package, it initializes all variables inside base since you defined from base import * inside __init__.py
I think that it is the Environment error,you should try setting : DJANGO_SETTINGS_MODULE='correctly_settings'
For anyone using PyCharm: the green "Run selected configuration" button would produce this error, yet running the following works:
py manage.py runserver 127.0.0.1:8000 --settings=app_name.settings.development
To fix this you need to edit the configuration's environment variables. To do this click the "Select run/debug configuration" drop-down menu to the left of the green run button and then click on "edit configuration". Under the "environment" tab change the environment variable DJANGO_SETTINGS_MODULE to app_name.settings.development.
for development just update settings.py, and should work
SECRET_KEY = '*'
In the init.py of the settings directory write the correct import, like:
from Project.settings.base import *
No need to change wsgi.py or manage.py
I solved this problem occurring on OS X with Django both 1.5 and 1.6 by deactivating all active sessions to virtualenv and starting it again.
To throw another potential solution into the mix, I had a settings folder as well as a settings.py in my project dir. (I was switching back from environment-based settings files to one file. I have since reconsidered.)
Python was getting confused about whether I wanted to import project/settings.py or project/settings/__init__.py. I removed the settings dir and everything now works fine.
I just wanted to add that I got this error when my database name was spelled wrong in my settings.py file so the DB couldn't be created.
I solved this problem on 1.8.4 by fixing the TEMPLATES settings which had a typo (removing TEMPLATES['debug'] solved it)
Go over the settings that you have changed recently, make sure all keys are by-the-book.
My Mac OS didn't like that it didn't find the env variable set in the settings file:
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = os.environ.get('MY_SERVER_ENV_VAR_NAME')
but after adding the env var to my local Mac OS dev environment, the error disappeared:
export MY_SERVER_ENV_VAR_NAME ='fake dev security key that is longer than 50 characters.'
In my case, I also needed to add the --settings param:
python3 manage.py check --deploy --settings myappname.settings.production
where production.py is a file containing production specific settings inside a settings folder.
The issue for me was calling get_text_noop in the LANGUAGES iterable.
Changing
LANGUAGES = (
('en-gb', get_text_noop('British English')),
('fr', get_text_noop('French')),
)
to
from django.utils.translation import gettext_lazy as _
LANGUAGES = (
('en-gb', _('British English')),
('fr', _('French')),
)
in the base settings file resolved the ImproperlyConfigured: The SECRET_KEY setting must not be empty exception.
The reason why there are so many different answers is because the exception probably doesn't have anything to do with the SECRET_KEY.
It is probably an earlier exception that is being swallowed.
Turn on debugging using DEBUG=True to see the real exception.
In my case, it was because I was trying to setup django-environ and I missed an important step:
Note: In the instructions below .env.example and .env should be saved in the same folder as settings.py
I incorrectly assumed that .env belonged in the root of my project. Moving it to the same folder as settings.py fixed the problem.
This error message in the Python console was the clue that set me on the right path:
Warning: /Users/allen/PycharmProjects/myapp/myapp/.env doesn't exist - if you're not configuring your environment separately, create one.
I solved this problem by removing the spaces around equal signs (=) in my .env file.
In my case the problem was - I had my app_folder and settings.py in it. Then I decided to make Settings folder inside app_folder - and that made a collision with settings.py. Just renamed that Settings folder - and everything worked.
I solved the above problem by commenting the line in my settings.py
SECRET_KEY=os.environ.get('SECRET_KEY')
SECRET_KEY declared in my ~/.bashrc file(for linux Ubuntu users)
For development purpose on my localmachine I did not use evironmnet variable
SECRET_KEY = '(i9b4aes#h1)m3h_8jh^duxrdh$4pu8-q5vkba2yf$ptd1lev_'
above line didn't give the error
In my case, while setting up a Github action I just forgot to add the env variables to the yml file:
jobs:
build:
env:
VAR1: 1
VAR2: 5
In my case, after a long search I found that PyCharm in your Django settings (Settings > Languages & Frameworks > Django) had the configuration file field undefined. You should make this field point to your project's settings file. Then, you must open the Run / Debug settings and remove the environment variable DJANGO_SETTINGS_MODULE = existing path.
This happens because the Django plugin in PyCharm forces the configuration of the framework. So there is no point in configuring any os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myapp.settings')
Import base.py in __init__.py alone. make sure you won't repeat the same configuration again!.
set environment variable
SET DJANGO_DEVELOPMENT =dev
settings/
__init__.py
base.py
local.py
production.py
In __init__.py
from .base import *
if os.environ.get('DJANGO_DEVELOPMENT')=='prod':
from .production import *
else:
from .local import *
In base.py configured the global configurations. except for Database. like
SECRET_KEY, ALLOWED_HOSTS,INSTALLED_APPS,MIDDLEWARE .. etc....
In local.py
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'database',
'USER': 'postgres',
'PASSWORD': 'password',
'HOST': 'localhost',
'PORT': '5432',
}
}
I came here looking for answer as I was facing the same issues, none of the answers here worked for me. Then after searching in other websites i stumbled upon this simple fix. It worked for me
wsgi.py
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'yourProject.settings')
to
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'yourProject.settings.dev')
Let me share m interesting solution!
I put the
SECRET_KEY = "***&^%$#" in settings packages init.py file and the error disappeared! it's actually a loading problem!
Hope this quick workaround is useful for some of you!
try import django then run django.setup() after the secret_key definition. like so:
SECRET_KEY = 'it5bs))q6toz-1gwf(+j+f9#rd8%_-0nx)p-2!egr*y1o51=45XXCV'
django.setup()
For anyone using Wing IDE: set the DJANGO_SETTINGS_MODULE in your project properties to DJANGO_SETTINGS_MODULE=${DJANGO_SITENAME}.config.settings.development
You will find the settings under: Project --> Project Properties and set the value in the field Environment
(I am using Pycharm, I also tried every solution in here and found out that the solutions works on some codes and some doesn't so I just did this solution)
The easiest Resolution that I did is I deleted the LIB where the installed sitepackages are, opened python interpreter in the settings and then it gave me an option where the program(Pycharm) installed the pip/sitepackges and I reinstalled the rest of the packges for example rest_framewrok etc. in the virtual environment of the project using cmd(or any command prompt tool) and it fixed my problem.
I apologize for the abundance of code/config posted - but I'm struggling to find the error and was hoping somebody may be able to spot it. This is my first time working with django/virtualenv so I'm sure it's probably something dumb. For the record, I am using Python 2.7 and Django 1.5. I am on a shared server, but I have a virtual environment with all the necessary dependencies.
Now, I'm able to see the Django welcome screen when my .urls has all the admin pages commented out. However, I've been setting up a sqlite3 (I know it's advised against for production) database to handle my one app, called users.
I can successfully add objects of type User to the database using the python shell. So it's not a database issue. As far as I can tell, as it tries to render the webpage at some point it is calling for the module users, but can't locate it. So, it must be calling from outside the project directory. Which makes me think I need to add something to my path perhaps? But what do i add?
I have a symlink in my virtualenv site-packages directory to the inner folder of my project - namely project/project (Which is internal of the app user ). So my guess is I need to change that symlink to point to the outer project directory instead?
My project structure is as follows:
/project
/project/project_db
/project/manage.py
/project/users/__init__.py
/project/users/admin.py
/project/users/models.py
/project/users/tests.py
/project/users/views.py
/project/project/__init__.py
/project/project/settings.py
/project/project/urls.py
/project/project/wsgi.py
Now, the relevant files:
/project/project/settings.py
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3', # Add 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'.
'NAME': 'project_db', # Or path to database file if using sqlite3.
# The following settings are not used with sqlite3:
'USER': '',
'PASSWORD': '',
'HOST': '', # Empty for localhost through domain sockets or '127.0.0.1' for localhost through TCP.
'PORT': '', # Set to empty string for default.
}
}
#...
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.staticfiles',
# Uncomment the next line to enable the admin:
'django.contrib.admin',
# Uncomment the next line to enable admin documentation:
# 'django.contrib.admindocs',
'users',
)
Next:
/project/users/models.py
from django.db import models
# Create your models here.
class User(models.Model):
CRAWFORD = 'CR'
CARPENTER = 'CA'
NOTAPPLICABLE = 'NA'
HALL_CHOICES = (
(CRAWFORD, 'Crawford'),
(CARPENTER, 'Carpenter'),
(NOTAPPLICABLE, 'Not Applicable'),
)
hall = models.CharField(max_length=2,choices=HALL_CHOICES,default=NOTAPPLICABLE)
email = models.CharField(max_length=256)
password = models.CharField(max_length=32)
supervisor = models.ForeignKey('self',blank=True, null=True, default=None)
def __unicode__(self):
return self.email + " " + self.hall
Lastly: .bash_profile
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
export PATH=$PATH:$HOME/bin:$HOME/virtual/lib/python2.7/site-packages/django/bin:$HOME/website/project
export PYTHONPATH=$PYTHONPATH:$HOME/virtual/lib/python2.7/site-packages:$HOME/website/project
Assuming the .bash_profile you posted is from your home directory, and you're running apache in the usual way, i.e. as a daemon process started by user root and forking children as user www-data or apache or somesuch, then the PYTHONPATH won't apply to the apache process, so you'll have to configure it separately.
If you're using mod_wsgi, then you can add the following apache directive to your webserver config...
WSGIPythonPath $HOME/virtual/lib/python2.7/site-packages:$HOME/website/project
...ensuring you substitute $HOME for the full, absolute pathname to your home directory, since it won't be the same for the apache user.
Update
According to the guide, you should have created a file ~/public_html/dispatch.fcgi, containing something like...
#!/usr/local/bin/python2.6
import sys
import os
# Make sure to change 'username' to your username!
sys.path.append('/home/username/local/lib/python2.6/site-packages')
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproj.settings'
from django.core.servers.fastcgi import runfastcgi
runfastcgi(method="threaded", daemonize="false")
...so check you've put the correct paths in the sys.path.append() line(s).
I've solved the issue. Upon reading the tutorial for fastcgi closer - it noted that you may need to add a symlink to the public_html directory for any packages external to the inner project directory. So, since my apps exist within the project but exterior of the inner project directory - fastcgi needs a link to the module in the public_html.