Django Framework — Best Practices
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.
The Django design philosophies are :
- Lose Coupling
- Less Code
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.
- Install pip first
sudo apt-get install python3-pip
- Then install virtualenv using pip3
sudo pip3 install virtualenv
- After installing, create a new virtual environment for your project by typing:
- Active your virtual environment:
- 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 :~$
- To deactivate your virtual environment
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
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
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.
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
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
(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
from .base import *
DEBUG = True
For your production environment create:
(project_name) $ nano settings/production.py
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.txtfile up to date and using it continuously in your work flow
- Setting up a better project settings array