Files
@ 562fa38d39b4
Branch filter:
Location: majic-django-templates/docs/usage.rst
562fa38d39b4
9.5 KiB
text/prs.fallenstein.rst
MDT-3: Added ALLOWED_HOSTS to development.py for consistency. Renamed testing.py to test.py. Added requirements files to support specifying what packages need to be installed in what environment.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 | Usage
=====
*Majic Django Templates* are utilised through the ``django-admin startproject``
and ``django-admin startapp`` commands.
Depending on Django version, you will need to pick the correct template
variation - either for your application or for your Django project.
For example, to start a new Django project, using version 1.8 run the command::
django-admin startproject --template /path/to/majic-django-templates/project-django-1.8/ your_project_name
Currently the following project templates are available:
- ``project-django-1.8``
Main difference when using one of the *Majic Django Templates* project templates
compared to regular, built-in Django project template is separation of settings
into base, and per-environment files (whereas stock Django has only one
``settings.py`` configuration file). You can read more about this in the next
section.
Common project template structure
---------------------------------
Despite having certain differences, all project templates share a common
structure and logic behind separation of settings files.
Each project template contains a number of distinct settings files.
At the very least, a base settings file (``settings/base.py``) is provided. This
file is used for specifying common configuration options that are shared across
all environments. This is a perfect place to specify things like installed
applications, or application-specific settings.
By default project templates come with additional environment-specific settings
files. These settings files build upon the base settings file
(``settings/base.py``) by importing all of the avaible settings from it. This
allows you to both add and override some of the settings from the base
file. Since they are just plain Python files, this means you can also do some
programatic manipulation of varible defined in base settings file.
The following environment-specific settings files are available:
- ``settings/development.py``, used for development environment running on
developer's machine. Full debugging is enabled within this file, and if you
run the application server against this file you should not expose it to the
outside. In order to reduce effort during development, this settings file
contains static credentials wherever possible.
- ``settings/testing.py``, used for testing environment.
- ``settings/staging.py``, used for staging environment.
- ``settings/production.py``, used for production environment.
.. note:
The ``settings/testing.py``, ``settings/staging.py``, and
``settings/production.py`` files are initially usually identical in content
(when you start a new project).
This layout allows for a lot of flexibility, and makes it possible to also
easily introduce additional environments - just pick one of the shipped settings
file as starting point, and create a new environment's settings file. You can
also opt to rename a settings file to better suit your naming conventions. For
example, you may opt to rename ``settings/staging.py`` to
``settings/acceptance.py``.
The following are the main items that are set on per-environment basis:
- Usernames.
- Environment-specific FQDNs and hostnames.
- Environment-specific URLs.
The only environment-specific settings that should be excluded from the
above-listed files are secrets and passwords. At the very least, this usually
involves database password, and Django's ``SECRET_KEY`` setting.
These credentials are best stored in a local ``credentials.py`` file, which
should be put into ``settings/`` directory, but excluded from version
control. Credentials file needs to have at minimum the following credentials
(variables) set within:
- ``SECRET_KEY``, which can be generated with the following one-liner::
python -c "import random; print(''.join([random.SystemRandom().choice('abcdefghijklmnopqrstuvwxyz0123456789\!@#$%^&*(-_=+)') for i in range(50)]))"
- ``DATABASE_PASSWORD``, which should hold database password for the environment.
Project template for Django 1.8
-------------------------------
Project template can be found in sub-directory ``project-django-1.8``.
In order to get started with a project using this template, perform the
following steps:
1. Start your project using custom project template::
django-admin startproject --template /path/to/majic-django-templates/project-django-1.8 myproject
2. Configure database in files ``myproject/myproject/settings/testing.py``,
``myproject/myproject/settings/staging.py``, and
``myproject/myproject/settings/production.py``.
.. warning:
Make sure not to touch database password in any of these files.
3. In order to make your life easier, it is recommended that you modify your
Python virtual environments (you *are* using ``virtualenv``, aren't you?) to
reference correct settings file via ``DJANGO_SETTINGS_MODULE`` environment
variable. This can be easily done in file ``$VIRTUALENV/bin/postactivate``,
just add a line (where ``ENVIRONMENT`` is the environment you the virtualenv
belongs to, for example ``development``)::
export DJANGO_SETTINGS_MODULE="myproject.settings.ENVIRONMENT"
If you do not do this, you will need to be passing --settings to every Django
command run - which can get very tedious very fast.
Once you create a new project based on this template, in the project's directory
(at the same level as the ``manage.py`` file), a directory called ``settings``
is created instead of ``settings.py.`` Within this directory, the following
files are present:
* ``base.py`` provides a place to define common configuration options that would
be shared amongst all of the different environments the project is deployed
in. All of the other environment-specific configuration files will import all
settings from this one, and build upon them. This is the right place to define
your project's applications, common application settings, middlewares etc.
* ``sample_credentials.py`` provides an example on how the ``credentials.py``,
which is environment-specific, should look like in order to be able to run a
project. This file is mainly used for defining things like database passwords,
``SECRET_KEY`` etc (that is any sort of credentials that should not be shared).
* ``development.py`` comes with some additional settings which are well-suited
for the development environments. This mainly revolves around using the
``sqlite3`` database, and enabling debugging.
* ``testing.py`` should be used for deploying the project in a testing
environment. It should be noted that it is a good idea to have this
configuration as close to the production one as possible, but the separate
file is provided for easier customisation for a test environment. Things like
database settings will probably differ between the two environments. It may
also be necessary to enable some custom settings in test environment that
might not be desirable to enable in development environment (for example
debugging).
* ``production.py`` is used for deploying the project in a production
environment. You should be very careful not to mess this file up, and make
sure that things like debugging etc are turned off (unless you really, really
need it in development environment).
There is very little in special variables used in the listed configuration
files. You can practically specify any Django or Django application
configuration where you wish to. There are only two special variables that are
project template-specific - ``DATABASE_PASSWORDS`` and ``SECRET_KEY``.
The ``SECRET_KEY`` must be specified in the ``credentials.py`` file, and its
syntax and meaning is the same as described in Django documentation.
The ``DATABASE_PASSWORDS`` is a dictionary, where keys are the database names,
and values are the corresponding passwords.
For example, let's say you define two databases for Django in ``production.py``
(in the Django ``DATABASES`` variable). Following the template layout, you would
make it look something similar to::
.. highlight:: python
DATABASES = {
'database1': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'database1',
'USER': 'database1_user',
'PASSWORD': DATABASE_PASSWORDS['database1'],
'HOST': '127.0.0.1',
'PORT': '',
},
'database2': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'database2',
'USER': 'database2_user',
'PASSWORD': DATABASE_PASSWORDS['database2'],
'HOST': '127.0.0.1',
'PORT': '',
}
}
Subsequently, when deploying the production environment, you would create the
``credentials.py`` file in the same directory with the following content::
.. highlight:: python
DATABASE_PASSWORDS['database1']="database1_password
DATABASE_PASSWORDS['database2']="database2_password
.. warning:: Make sure that the ``credentials.py`` is never part of your version
control system history! It is highly recommended to keep this file
in ``.gitignore``, ``.hgignore``, or whatever the equivalent of
your version control system is!
In order to run your Django project with different settings, you would use one
of the following commands (depending on which environment you want to run)::
python manage.py runserver --settings your_project_name.settings.development
python manage.py runserver --settings your_project_name.settings.testing
python manage.py runserver --settings your_project_name.settings.production
If using ``virtualenv``, you may want to set the ``DJANGO_SETTINGS_MODULE``
environment variable in it to make your life easier.
|