I am making web application where I want to set some constant's globally so I can access it in multiple apps present in my Django project.
Define the constant in your settings file
MY_CONSTANT = 123
Then use it in the following way:
from django.conf import settings
print(settings.MY_CONSTANT)
Related
Despite googling I can't find any documentation for the Django HOST_DOMAIN setting in the settings.py.
I am going through a settings.py file I have been given and this is the only part of the file I am not 100% clear on.
You can find out what are all the django specific settings at the settings reference which lists all the settings variables (and their defaults) that are set by django.
Since settings.py is just any other Python module, you are free to define your own variables and import them in your code with:
from django.conf import settings
settings.MY_CUSTOM_SETTING
Third party applications can also define their own settings, which you can modify by entering the specific value in settings.py.
It sounds like HOST_DOMAIN is one such custom setting.
That is not a Django setting.
It's perfectly good practice to define your own project-specific settings inside settings.py, and that is presumably what the original developer did here.
I often run my django development server with different settings given as parameter as shown in the example below:
python manage.py runserver --settings=my_project.settings.andi
But sometimes it is .andi and sometimes something .other.
How to make universal import statement, which will be able to access this settings always?
TO make clear how it works, and answer to the suggestion Santosh Ghimire:
I have base.py which I import in any other (e.g andi) with statetment from .base import *
The way to access the things, which are extra added in andi is the one proposed by bruno desthuilliers, i.e with:
from django.conf import settings
If your question is "how do my django apps modules know which settings to import", the answer is simply to replace any import settings with from django.conf import settings.
Why don't you separate these different settings in separate files like settings_local.py and settings_remote.py and import each one on necessity in the main settings.py file that holds all the common settings.
This way you won't have to give optional parameters in the runserver command.
I was wondering about whether it is better to import variables into your view from the settings.py file? or better to create a configuration file with the variables that are needed?
I tend to like to write configuration files for my Django applications, read, and import the variables from there when necessary. For example:
.configrc
[awesomeVariables]
someMagicNumber = 7
views.py
from ConfigParser import SafeConfigParser
#Open and parse the file
config = SafeConfigParser()
config.read(pathToConfig)
#Get variable
magicNumber = config.get('awesomeVariables', 'someMagicNumber'))
However, I've noticed some programmers prefer the following :
settings.py
SOME_MAGIC_NUMBER=7
views.py
import settings
magicNumber = settings.SOME_MAGIC_NUMBER
I was curious as to the pros and cons of the different methods? Can importing variables directly from your settings compromise the integrity of the architecture?
It's a judgement call. Using the settings module is the "Django way", although you should do from django.conf import settings; settings.MY_SETTING, which will respect DJANGO_SETTINGS_MODULE. But Django is just Python; there's nothing that will stop you from using ConfigParser. In the interest of having only one place where such things are defined, I'd recommend putting it in the Django settings file - but if you have a reason not to, don't.
Using a config file is completely un-Django. Settings go in settings.py. Period. For app-specific settings, you simply set a default in your app and allow the user to override in their project's settings.py:
from django.conf import settings
SOME_MAGIC_NUMBER = settings.SOME_MAGIC_NUMBER if hasattr(settings, 'SOME_MAGIC_NUMBER') else 0
# Where `0` is the default value
There also an app for storing settings dynamically in db. Maybe you find it usefull .
django-constance
I want to keep some global settings for my project in Django. I need to have access to these settings from the code. For example, I need to set a current theme for my site that I can set using admin console or from the code. Or I need to set a tagline that will show in the header of all pages. I suppose I should use models for keeping the settings but I can't realize how I should better do it.
There are quite some packages that store settings in models, pick the one that works best for you:
http://pypi.python.org/pypi?:action=search&term=django+settings&submit=search
If you are okay with changing these setting programmatically via settings.py you should do that. However, if you want to change these settings via the Admin Console, you should use models.
It is sometimes beneficial to share certain constants between various code files in a django application.
Examples:
- Name or location of dump file used in various modules\commands etc
- Debug mode on\off for the entire app
- Site specific configuration
What would be the elegant\pythonic way of doing this?
There's already a project-wide settings.py file. This is the perfect place to put your own custom setttings.
you can provide settings in your settings.py like
MY_SETTING = 'value'
and in any module you can fetch it like
from django.conf import settings
settings.MY_SETTING
Create a configuration module.
Configuration.py: (in your project/app source directory)
MYCONST1 = 1
MYCONST2 = "rabbit"
Import it from other source files:
from Configuration import MYCONST1,MYCONST2
...
Django apps are meant to be (more or less) pluggable. Therefore, you are not supposed to hack into the code of an app in order to parametrize what you want (it would be quite a mess if you had to do this ! Imagine you want to upgrade an app you downloaded on internet... you would have to re-hack into the code of the new version ?!?).
For this reason you shouldn't add app-level settings at the app level, but rather put them together somewhere in your project-wide settings.py.