Introduction

Django is a Web framework written in Python. But that’s an abstract definition. In practice, Django is a Python package that lives inside the site-packages directory of your current Python installation. That means it lives alongside with other Python packages, such as Requests, Pillow and NumPy.

A simple way to verify a Django installation is importing it in a Python shell:

>>> import django
>>> print(django.get_version())
1.11.4

But the way we interact with Django is a little bit different than the way we interact with other Python packages. Usually we don’t import it directly into our Python programs to make use of its resources.

When we first start learning Django, we are taught that we should start a new project using the django-admin command-line utility by executing the startproject command.

The startproject command creates a basic Django project directory structure with the following files:

• manage.py
• settings.py
• urls.py
• wsgi.py

The contents of the files above are essentially a boilerplate code that’s generated using the templates inside the django.conf.project_template folder. It’s like a pre-configuration of commonly used resources.

For example, if you are going to develop a Web application, the chances are that you will need a database, handle user authentication, work with sessions, and so on. The boilerplate code from the startproject command makes our life easier. But that’s not the only way to start a new project. We could start everything from scratch. And that’s sort of what we are going to do in this article.

Also, the names are purely convention, which is a good thing because whenever you browse an existing Django project it’s easier to know where to find certain things.

Running a Project Locally

To run the the development server, we usually execute the following command:

python manage.py runserver

The manage.py script is automatically generated when we start a new Django project by running the command:

django-admin startproject myproject

Basically the django-admin and manage.py do the same things. The main difference is that manage.py adds your project’s package in the sys.path and sets the environment variable DJANGO_SETTINGS_MODULE to point to your settings.py file.

That means we could run the development server of my project using the django-admin command-line utility. The difference is that we would need to provide manually the information of the path to my project’s package and the settings.py.

So, considering my project is in the following path: /home/projects/myproject, we can start the development server like this:

django-admin runserver --pythonpath='/home/projects/myproject' --settings=myproject.settings

Or if you are currently in the project root in the file system, you could perhaps do this to save typing:

django-admin runserver --pythonpath=. --settings=myproject.settings

As you can see, the settings.py module is the starting point of every Django project. It’s the file responsible for putting the pieces together and instructing Django on how to run our project; which apps are installed, what database the project uses (if any), the credentials to connect, where to find the project’s templates, the urls, the wsgi module and many other important configurations.

The name settings.py is just a convention. We could use any other name. As far as we tell Django where to find the required information.

The Settings Module

Now that we know the settings module is the central part to run our project, what’s the bare minimum configuration we need to feed Django, so to start the development server?

Before we answer that question, know that Django comes pre-configured. Before loading your project’s settings module, Django will load the global settings that can be found in the django.conf.global_settings.py file.

The link above takes you to the file directly in the Django’s GitHub repository. Take a moment and check it out.

What happen when Django finally loads your project’s settings module, is that it will override the default values from the global_settings.py.

The global_settings.py doesn’t have all the necessary information. We will need to provide at least a SECRET_KEY.

If you check the Django’s global_settings.py file, you will see right at the top of the file that the DEBUG configuration defaults to False. If you don’t override it to True, you will also need to configure the ALLOWED_HOSTS variable.

So, the bare minimum configuration just to successfully start the development server could be either defining the SECRET_KEY and DEBUG=True, or SECRET_KEY and ALLOWED_HOSTS.

See examples at https://simpleisbetterthancomplex.com/article/2017/08/07/a-minimal-django-application.html

Simplification

(softwaremaniacs) You need to abandon the startproject command. It creates a nice skeleton of the project with an annotated settings file, but if this is not your first time seeing the Django project, this can be neglected.

The manage.py file is not needed either, it's just a local helper for django-admin.py

You don't need to think of the project as a container for applications, and therefore you don't need to design your code as a pluggable application. Applications are one of the strongest architectural features of Django, but for small tasks this flexibility will never be needed.

As a result, we have something like this:

• settings.py:

DEBUG = True
ROOT_URLCONF = 'urls'
TEMPLATE_DIRS = ['.']

• urls.py:

from django.conf.urls.defaults import *
import views

urlpatterns = patterns('',
    (r'^$', views.index),
    (r'^test/(\d+)/$', views.test),
)

• views.py:

from django.shortcuts import render

def index(request):
    return render(request, 'index.html', {})

def test(request, id):
    return render(request, 'test.html', {'id': id})

This is a fully working Django project. Started by the command:

django-admin.py --settings=settings runserver

You get Djang's request-response pipeline, templates. Also, nothing should prevent such a good thing as a form library from working, although I have not really tested it. What you lose is the ORM and the applications tied to it. But that is why this task is “micro”.

Extreme

(softwaremaniacs) In order to find the borderline of when the idea reaches the point of absurdity, I decided to collect the entire application into one self-launching file . And I got it:

• web.py:

#### Setup

from django.conf import settings
if not settings.configured:
    settings.configure(
        DEBUG = True,
        ROOT_URLCONF = 'web',
        TEMPLATE_DIRS = ['.'],
    )

from django.conf.urls.defaults import patterns
urlpatterns = patterns('',
    (r'^$', 'web.index'),
    (r'^test/(\d+)/$', 'web.test'),
)

#### Handlers

from django.shortcuts import render

def index(request):
    return render(request, 'index.html', {})

def test(request, id):
    return render(request, 'test.html', {'id': id})

#### Running

if __name__ == '__main__':
    from django.core.management import execute_from_command_line
    execute_from_command_line()

The file starts like this:

python web.py runserver

However, I did not see much joy from such an assembly. For a file to be readable, it has to be divided into named sections, which, as it were, tells us that these must be different files. Plus, I would still not be able to write such a file out of my head due to the fact that a lot has to be done from memory: protection against double configuration of settings, long imports, etc.

But as a fact - it's funny .

Side idea

(softwaremaniacs) Digging through the initialization of the project, I found that the setting ROOT_URLCONF is used in the very core of request processing. This binds Django's work to the presence of a real module with a variable defined in it urlpatterns. Django would be more flexible if the URL configuration could be initialized programmatically with a simple list:

settings.configure(
    DEBUG = True,
    urlconf = [
        (r'^$', index),
    ],
)

It would probably even be useful in practice, when you need to be able to create an environment on the fly. For example, when testing.

A “Hello World” for Django…Because Django can be nearly as simple as Flask.

The aim of this repository is to highlight the fact that a Django project, when simplified down to the bare essentials, can be nearly as minimal as a micro-framework application.

To run it:

1. Install Python
2. Install Django. If you have pip: pip install Django
3. Clone this repository: git clone https://github.com/rnevius/minimal-django.git
4. Switch to the project directory: cd minimal-django
5. Run the development server: python minimal.py runserver
6. Open a browser to http://127.0.0.1:8000/

import sys

from django.conf import settings
from django.conf.urls import url
from django.core.management import execute_from_command_line
from django.http import HttpResponse

settings.configure(
    DEBUG=True,
    ROOT_URLCONF=sys.modules[__name__],
)


def index(request):
    return HttpResponse('<h1>A minimal Django response!</h1>')

urlpatterns = [
    url(r'^$', index),
]

if __name__ == '__main__':
    execute_from_command_line(sys.argv)