Django Framework — Best Practices

Gowthamy Vaseekaran
5 min readJan 26, 2020
django logo

Django is an open source python based framework that helps to build web applications. The popularity of this framework increased rapidly in last couple of years. Compare to other python-based frameworks like Flask and Pyramid, django framework is far most popular among python developers. It supports both Python 2.7 version and Python 3.6 version.

Google trends of the 3 most popular Python web development frameworks

The Django design philosophies are :

  • Lose Coupling
  • Less Code
  • Dry
  • Consistency

As a python and django developer, I am writing this article to explain the good practices for Django framework. I assume that the readers are using a Linux Ubuntu Machine. Lets Begin:

1. Create Virtual Environment

While developing any python based applications, third party libraries installation is an inseparable requirement. Keeping them in an organizing manner is an essential thing as those packages are updated often. When we developing multiple python application in the same local machine, it’s really hard to keep track of each and every packages. It’s not possible to use different version of the packages for multiple projects. Sometimes updating a package for one project can break other project setups.

The solution for the above problem is, using Virtual Environments. To install virtual environment please follow following instructions.

  1. Install pip first
    sudo apt-get install python3-pip
  2. Then install virtualenv using pip3
    sudo pip3 install virtualenv
  3. After installing, create a new virtual environment for your project by typing:
    virtualenv venv
  4. Active your virtual environment:
    source venv/bin/activate
  5. While you’re in the context of your virtual environment, you’ll notice that a prefix is added to the terminal, like:
    (project_name) gowthamy@gowthamy-Vostro-3580 :~$
  6. To deactivate your virtual environment
    deactivate

Holding your project dependencies (packages) in a virtual environment on your machine allows you to keep them in an isolated environment. You only use them for a single (or multiple) projects. When creating a new virtual environment, you’re starting a fresh environment with no packages installed in it.

Lets say you want to install django 1.11 in your virtual environment for your current project. First activate the specific virtual environment and type
(project_name) $ pip install Django==1.11

for installing version 1.11 of Django accessible only from within the environment. Neither your main Python interpreter nor the other virtual environments on your machine will be able to access the new Django package you’ve just installed.

2. Maintaining requirements.txt file

Requirements are the list of Python packages (dependencies) of your project that are used by the project while it runs. It includes the version for each package. Here’s an example for a requirements.txt file:

attrs==19.3.0
Click==7.0
cubes==1.1
expressions==0.2.3
Flask==1.1.1
grako==3.99.9
importlib-metadata==0.23
itsdangerous==1.1.0
Jinja2==2.10.3
jsonschema==3.1.1
MarkupSafe==1.1.1
more-itertools==7.2.0
psycopg2==2.8.4
pyrsistent==0.15.4
python-dateutil==2.8.0
six==1.12.0
SQLAlchemy==1.3.10
Werkzeug==0.16.0
zipp==0.6.0

Maintaining your requirement.txt up-to-date is very important for collaborating with other developers. It’s also helps to keep your production environment properly configured. When we include requirement.txt file in your code repository, it enables you to update all the installed packages in your virtual environment by executing a single line in the terminal. Then you can get new developers up and running in no time.

If a new developer joins the team, or if you want to configure a new environment using the same packages listed in the requirements.txt file, execute in the virtual environment context:
(project_name) $ pip3 install -r requirments.txt

All requirements listed in the file will immediately be installed in your virtual environment. Older versions will be updated and newer versions will be downgraded to fit the exact list of requirements.txt.

I highly recommend integrating these commands to your work flow. Update the requirements.txt file before pushing code to the repository and install requirements.txt file after pulling code from the repository.

3. Better settings.py configuration

The settings module is the only true requirement for a Django project. Typically, it places in the root of your project as settings.py.This contains the main and most essential configurations for the project. It is very straightforward. But sometimes, as a developer working on a team, or when setting up a production environment, you need more than one basic settings.py file.

There is an extended approach for configuring the settings.py file. It allows you to maintain different versions and use the one you want at any given time and in any environment.

First, navigate to your settings.py file path:

(project_name) $ cd /path/to/settings-file

Then create a new module called settings (module is a folder containing an __init__.py file):

(project_name) $ mkdir settings

Now, rename your settings.py file to base.py and place it inside the new module you created:

(project_name) $ mv settings.py settings/base.py

For this example, I assume that you want to configure one settings file for your development environment and one for your production environment. Different developers on the same team can use the exact same approach for defining different settings files.

For your development environment create:

(project_name) $ nano settings/development.py

Then type:

from .base import *

DEBUG = True

For your production environment create:

(project_name) $ nano settings/production.py

and type:

from .base import *

DEBUG = False
ALLOWED_HOSTS = [‘app.project_name.com’, ]

Now, whenever you want to add or update the settings of a specific environment, you can easily do it in its own settings file.

You might be wondering — how does Django know which settings file to load on each environment? That’s what the __init__.py file is used for. When Django looks for the settings.py it used to load when running the server, for example, it now finds a settings module rather than a settings.py file. But as long as it’s a module containing an __init__.py file, as far as Django is concerned, it’s the exact same thing. Django will load the __init__.py file and execute whatever is written in it.

Therefore, we need to define which settings file we want to load inside the __init__.py file by executing:

(project_name) $ settings/__init__.py

In this blog we’ve covered three best practices for better setting up a Django project:

  • Working inside a virtual environment
  • Keeping the requirements.txt file up to date and using it continuously in your work flow
  • Setting up a better project settings array

--

--

Gowthamy Vaseekaran

Senior Software Engineer @ hSenid Mobile | Former Software Engineering Intern @ WSO2 | Software Engineering Undergraduate @ IIT