Here in comments to the answer, somebody asked this questions. But answer is still unclear for me .
I run my django site in Herouku and it requires dj-database-url module to work with Postgresql. How to run django with DATABASES = dj-database-url() in settings.py on my local computer? Changing code before pushing to Heroku is a pretty ugly way.
There are many ways to handle different production / development environments.
One is to have a local settings file that's imported at the bottom of your settings file that's not in version control, and thus not in heroku.
Another is any way to distinguish heroku environment from your local environment. An arbitrary environment variable, for example.
Another, is the default argument passed to dj_database_url which basically does this simple if statement for you.
import dj_database_url
DATABASES['default'] = dj_database_url.config(
default='sqlite:////path-to-my/database.sqlite')
Remember, this settings file is just python. You could have it use one database on Tuesday for example.. any if statement you can come up with will work.
Related
My django app is communicating with external server and before running django server i would like load some config file. Variables from this file are going to be used by some module while app is running
Problem is that config file can be located in many places.
My dream would be to run manage.py --cfg "/path/to/cfg/file.cfg" or
manage.py runserver --cfg "/path/to/cfg/file.cfg"
and some variables (like globals?) are going to be loaded and they are going to be avaible for django modules to be used. After django server shutdown those variables can dissapear
Is there some nice way to accomplish this?
There seem to be two parts to your problem:
How do I support changing which set of variables (as defined in a config file) are used for a given run
How can I load these variables such that they are visible to all the modules of my application.
The standard mechanism for doing the 2nd is to put stuff in settings.py.
If you do FOO="bar" in settings.py, in your module you can do:
from django.conf import settings
if settings.FOO == "bar":
# Do something
As far as how you can support multiple configurations, the first thing I could come up with is to rename your real settings.py to be real_settings.py and then create a series of config1_settings.py, config2_settings.py, config3_settings.py ... which look like:
from real_settings.py import *
from path_to_configX.py import *
where configX.py has all the values for whatever variables you want for configuration X.
You would then start django's built in server via:
manage.py runserver --settings=configX_settings.py
Note that doing this for a production server (where you can't as easily just pass something on the command line to kick it off) may be a bit trickier, but you're going to need to provide more use case details for that.
How do I seperate production and development database in Django 1.8?
For now I'm doing the naive way using the same database for both dev and production. When deploying, the dev database are copied over production (SQLite).
What's the correct way to do this in Django 1.8? Additionally, how can I update production tables without losing previous data?
Well, first off, I would really recommend you to not use sqlite in production. If you insist, what I would do would be to make a copy of the sqlite file outside of the project structure, and use an additional settings file for live only, such as settings_live.py and override the DATABASES setting with the correct path:
from myproject.settings import *
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': ..., # the correct path file name here
}
}
Make sure that you specify the correct settings file in your production environment. For example, for wsgi:
os.environ.setdefault('DJANGO_SETTINGS_MODULE', wsgi_app + '.settings_live')
Update
Marina Mele has written a thorough article on the dual environment setup "thing".
In my setup, I have 2 or 3 different virtualenvs.
I also have a main settings.py with the basic parameters and different settings that inherit from the main and cater for each virtualenv.
The idea is described here and here.
In my .virtualenvs/bin/activate file I append the path to the relevant settings file:
DJANGO_SETTINGS_MODULE=air.settings.settingst
export DJANGO_SETTINGS_MODULE
This way, I have a separate database for each environment for the same project.
Trying to use 2 different settings file for production and dev.
I set DJANGO_SETTINGS_MODULE='mysite.settings_production'
Works perfectly when running server with runserver
When I run it with apache though, apache doesn't seem to use the setting in the ~/.bash_profile and instead use os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings") in the wsgi.py file
I guess it's maybe because apache is running on different user , not mine..
ok.. so it seems it's running as www-data on my ec2 ubuntu.
So I have to create the /home/www-data/.bash_profile and set the env variable?
It seems like so much hassle to use a different settings file.
Is there an obviously easier way to do this?
(I don't want to change the wsgi.py file, because it's source controlled)
Using bash_profile is completely the wrong way to do this.
The correct way is to use the wsgi.py file. However, since you don't want to do this (although I don't understand what it being version-controlled has to do with anything) then you can set environment variables directly in your Apache configuration using SetEnv:
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
Well, it's really wrong way. Common method to have separate settings for different environment is to store environment-dependent in local_settings.py (or whatever you name it) and imprort from settings.py
from local_settings.py import *
don't put local_settings.py under project repository as you will override it with each commit. If you want to keep a sample of local settings, put into a separate file, e.g. local_settings.py.example
You can import local settings at the beginning of settings.py (so settings.py settings would override local settings), or at the end, or have two local settings files for both cases.
I have been using Django a long time but I recently upgraded to 1.4.
When I created a new project, here is how it was made:
-my_proj
-my_app
-settings.py
-urls.py
-wsgi.py
-venv
-manage.py
-requirements.txt
I am working on my local machine as well as on Heroku. The issue is how I am supposed to refer to modules.
When I am on my local machine, everything seems like it is supposed to be referred to as my_proj.my_app. However, when I am on Heroku, everything has to be referred to as my_app.
Does anyone know of some areas that I should look that might be causing this problem?
Moving your my_app dir to the root directory of your project (where manage.py is located), as it was done in Django tutorial for Django 1.4 will make it a top level module and will allow you to import them just as my_app on your local machine. I would suggest trying this and checking whether Heroku behaves the same.
Alternatively, adding an empty __init__.py, if there there isn't one already, in your my_proj directory might also help Heroku see my_proj as a top-level module, thus allowing you to import your app as my_proj.my_app.
I hope my advice was insightful and helpful.
Good luck!
I'm new to Git. I need to setup Git to deploy a Django website to the production server. My question here is to know what is the best way of doing this.
By now I only have a Master branch. My problem here is that Development environment is not equal to the Production environment. How can I have the two environments(Development and Production) in Git? Should I use two new Branches(Development and Production). Please give me a clue on this.
Other question... when I finish to upload/push the code to the Production server I need to restart the Gunicorn(serves Django website). How can I do this?
And the most important question... Should I use Git to do this or I have better options?
Best Regards,
The first question you must solve is your project structure. Usually the difference between development and the production environment is setting.py and url.py. So why you firstly separate those? :) For example you can have one main settings.py where you define all the default settings which are in common. Then at the end of the file you just import the settings_dev.py and settting_prod.py for exemple:
try:
from settings_prod import *
except ImportError:
pass
try:
from settings_dev import *
except ImportError:
pass
Then simply you can overload all the setting you want and have custom settings of the project (for example installed apps). The same logic you can use for urls.py file.
Then you can simply ignore adding the *_dev files to repo and on the server side you can just checkout the code from repo and restart http server. To automatize this for now I can't give the right name of app to use. Sometimes simple python script could be solution like: watching if the file datetime changed and if yes, just run restart command for http.
Hope that helped.
Ignas
You can follow this brunching model - http://nvie.com/posts/a-successful-git-branching-model/
And, git is ok but use Fabric for deployment.