I'm following the approach in Two Scoops of Django: Best Practices for Django 1.6 regarding multiple settings files. I'm using Django 1.7 and virtualenvwrapper.
My setup is as follows:
project/
app1/
app2/
project/
__init__.py
settings/
__init__.py
base.py
local.py
production.py
manage.py
I'm a bit confused as to how Django knows which settings file to use. I do not want to specify the settings file every time I run manage.py. I would rather like to set the DJANG_SETTINGS_MODULE environmental variable as explained in omouse anser here:
What confuses me is in the wsgi.py file there is a line:
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "{{ project_name }}.settings.production")
Is this file only used in the production server? What happens if I already have a DJANGO_SETTINGS_MODULE environmental variable defined on the server?
When running it locally, I understand I need to set the DJANGO_SETTINGS_MODULE env variable every time I open the console. I've read here that I can define a postactivate hook in virtualenvwrapper. This hook will then create the environmental variables that I require everytime I activate the environment.
Is this the recommended way of ensuring the correct DJANGO_SETTINGS_MODULE env variable is loaded on my local machine? Would I also need to setup a similar file on my hosting server? I'm planning on using PythonAnywhere for hosting.
Lastly, if I run a staging server, how would I tell Django to load the staging settings file? The staging server is the practically the same as the production server, so I guess need a different wsgi.py file for the staging server, but that seems like a anti-pattern.
os.environ.setdefault only sets the value if it is not set. When you run in production, export the environment variable DJANGO_SETTINGS_MODULE and set it to your production/staging settings file, and you don't have to set anything when running in development (if you set it by default to your development settings). This is the DRY-est method.
The method with a local_settings.py (which is most of the times kept out of the repo!) is not best practice and should be avoided.
Related
I am deploying capistrano to Django project.
And database settings differs from local to server.
So at first I set linked_files in deploy.rb.
append :linked_files, "app/settings.py"
With this setting, deployment doesn't update the app/settings.py on server.
However sometimes, I need to add app setting to this file, so it should be synced to server's.
Is there any good practice to deploy django project by tools and keep only database setting in each server??
In such setups one way could be to use app/settings/local.local and app/settings/prod.py files. a make target should copy the app/settings/local.local file to app/settings/local.py and use this file. This way in settings you always have one .py file. all the changes to local.local are synced with git.
local.py should be added to gitignore. __init__.py in settings folder should import from all the py files.
settings
|
| -- __init__.py
| -- local.local
| -- prod.py
somethings like this.
I deployed my Django-project via Apache2 on a server.
The problem I have is that I have two setting-modules: settings.py which are my local development settings and settingsprod.py which are my productive settings.
I found the following line in the WSGI.py:
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "proj.settings")
Is this module only called when using WSGI? And if yes is this a good place to use my production settings like so?
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "proj.settingsprod")
For local development I use the development server like so:
python3 manage.py runserver
Does this still defaults to settings.py then?
Yes, your setup works as expected. Though if you use extra tools like celery, you might need to also specify the settingsprod for those setups aswell.
The way I handle such a situation is exactly the other way around: I use settings.py for my production settings and have an additional settings_development.py that I use for all development tasks. This way I don't have to remember setting the production settings in all production relevant files, but instead simply use the development settings for development like so:
python3 manage.py runserver --settings=proj.settings_development
If you often use manage.py commands and want to save some time typing, you can make a copy of your manage.py e.g. as manage_dev.py and change the settings module line like so:
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "proj.settings_development")
and then call your manage functions with:
python3 manage_dev.py runserver
Using Django 1.7 and it's new migration I am running into a strange issue.
I split my settings files up into 3 files which I have always done pre version 1.7 eg...
/settings
__init__.py
base.py
development.py
production.py
__init__.py
from .base import *
if sys.argv[1] == 'runserver':
from .development import *
else:
from .production import *
Both development.py and production.py have there own database settings for there environment. However with the new migrations system running migrations does not detect anything UNLESS I put the database settings in the base.py files.
Should I modifity this line to the following:
if sys.argv[1] == 'runserver' or sys.argv[1] == 'migrate':
Or there a better way?
You should avoid adding logic to your settings file, consider using che --settings option when testing with runserver, like this:
./manage.py --settings=project.settings.development runserver
You can also use environment variable DJANGO_SETTINGS_MODULE to switch the settings module used by Django.
In your development enviroment you could set:
export DJANGO_SETTINGS_MODULE=project.settings.development
While in production you could set DJANGO_SETTINGS_MODULE=project.settings.production.
The details depend on the type of deployment and server you are using.
Personally in my development setup I use virtualenv wrapper, and I set up the postactivate hook with something like this:
#!/bin/bash
# This hook is run after this virtualenv is activated.
export DJANGO_SETTINGS_MODULE=project.settings.local
cd /home/user/develop/git/project
In this way I can type
workon project
And I have the environment variable correctly set, and my shell sent on the right folder.
You can have a base.py settings file with all your common settings, then in development.py (and production.py) you can do something like this:
from .base import *
DATABASES = ... customize DB settings used for development/production ...
A note before the question
We generally have a settings.py file and a local_settings.py file in standard Django project layouts.
settings.py: for production settings
local_settings.py: for local settings that override production settings when running the project locally
The local_settings.py file is added to .gitignore to avoid being pushed into production via git push.
The question
In appengine when we push the application using:
appcfg.py update exampleproject
The local_settings.py file also gets pushed up even though it has been added to .gitignore.
At first adding the following lines to app.yaml looks like a possible solution:
skip_files:
- ^(.*/)?local_settings.py
These lines tell app engine to ignore the local_settings.py file.
But, then we face another problem ->
The local_settings.py file is totally excluded. ie. It is not even used when running the application locally along with dev_appserver.py.
Is there any good solution that can help define multiple settings files in a Google App Engine based Django project?
This is the first time I am trying to deploy my django project (myproject) on Webfaction.
My project dir-structure is as follows:
In webapps/django: myproject.wsgi, myproject
settings.py is at myproject/src/myproject/
Under such circumstances, how should I define DJANGO_SETTINGS_MODULE in myproject.wsgi?
For the default installation by webfaction, it is defined as myproject.settings. Should I be defining DJANGO_SETTINGS_MODULE as myproject.src.myproject.settings?
When you setup a Django project on webfaction, you get a file structure like so:
~ (your home directory)
+webapps
+some_project_name
+myproject
-standard django files
-settings.py
-app_directory
+apache2
+bin
-start
-stop
-restart
-other dirs
-bin
-lib
-myproject.wsgi
-some_project2
-symlink_to_static_files
If you are building your project under "myproject", you should not have to modify the wsgi file to get started- just change to the apache2/bin directory and run ./start and you're good to go!
If you change the wsgi file you'll need to run ./stop then ./start to activate the changes.
If the path you listed isn't working, it may be worth trying to create a generic django project and just puaste your project right over 'myproject'
It seems like your service provider has already given you some helpful instructions:
http://docs.webfaction.com/software/django/getting-started.html