0

I have an ec2 instance running Ubuntu 14.04 and I want to host two sites from it. On my first site I have two settings file, production_settings.py and settings.py (for local development). I import the local settings into the production settings and override any settings with the production settings file.

Since my production settings file is not the default settings.py name, I have to create an environment variable 

DJANGO_SETTINGS_MODULE='site1.production_settings'

However because of this whenever I try to start my second site it says

No module named site1.production_settings

I am assuming that this is due to me setting the environment variable. Another problem is that I won't be able to use different settings file for different sites.

How do I start use two different settings file for two different websites?

Will Hua
  • 1,729
  • 2
  • 23
  • 33
  • Even after you fix Python module search path issues, careful of how you set DJANGO_SETTINGS_MODULE in the WSGI script file. See http://blog.dscpl.com.au/2012/10/requests-running-in-wrong-django.html for more details of why. – Graham Dumpleton Jun 08 '14 at 03:23

1 Answers1

1

Edit: I missed the apache tag on this so I've updated my answer accordingly

Your problem is when running your Django app, site2, the python interpreter does not know about any of the modules in site1 because it's not listed in your PYTHONPATH.

I would highly recommend doing a short amount of reading up on how PYTHONPATH works before you continue: http://www.stereoplex.com/blog/understanding-imports-and-pythonpath

Now, there are many ways to resolve this, but we'll cover 3:

Modify your apache virtualhost configuration for site2:

Be sure to read the docs here, first, for differences between mod_wsgi v1 and v2 but as you're running ubuntu 14.04, you should be using mod_wsgi v2 anyway.

https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIPythonPath

<virtualhost *:80>
    # your existing config directives
    WSGIPythonPath /path/to/site1
</virtualhost>

This has the advantage of not modifying any of your application code and, potentially having invalid directories in your PYTHONPATH when running site2 on your development machine.

Append the path in your python code

Python sys.path - appending PYTHONPATH

In your site2.wsgi file, before you start your Django app, add the following code. 

import sys
sys.path.append('/path/to/site1')

Simple, and works. This approach will also not cause you problems when moving between development (using manage.py runserver) and production.

Create a simlink

How to symlink a file in Linux?

Another simple choice is to simply simlink your production_settings.py into site2, and and then set your DJANGO_SETTTINGS_MODULE='site2.production_settings'

ln -s /path/to/site1/site1/production_settings.py /path/to/site2/site2/production_settings.py

If you're developing on a windows machine, this is probably the most problematic of the 3 approaches, so if you're pushing to the server using git or any other version control system, make sure to add your new simlink to your .gitignore file or your VCS's equivalent.

Community
  • 1
  • 1
Derek Curtis
  • 639
  • 6
  • 14
  • Except that PYTHONPATH environment variables in a user account aren't consulted by Apache/mod_wsgi. Necessary to use the configuration options of mod_wsgi to specify them, or do it in the WSGI script file by amending sys.path. – Graham Dumpleton Jun 08 '14 at 03:21
  • That is true, but there's nothing in his question about Apache. – Derek Curtis Jun 08 '14 at 03:35
  • The set of tags mentions 'mod-wsgi' and 'apache'. That is a very good indication they are using mod_wsgi. – Graham Dumpleton Jun 08 '14 at 05:34
  • @GrahamDumpleton you're totally right.. Don't know how I skipped over that. I've updated my answer accordingly. – Derek Curtis Jun 08 '14 at 07:43
  • WSGIPythonPath can't be inside of VirtualHost. It can only go at 'server config' level in Apache configuration. If anyone is using mod_wsgi I would very much hope they are not using either version 1 or 2. Even version 3 is quite old now and has been on Linux distributions for years. – Graham Dumpleton Jun 08 '14 at 09:33