Project Structure for a Python Application

1. Project Structure for a Python Application
2. An example

When working on real-world applications, the size of the codebase can increase drastically. Generally, programming monolithic programs or putting all the application code in one single file is not recommended. The reason behind the same is that a monolithic program can create more unexpected bugs. It becomes unmanageable and unreadable as the size of the program increases and doesn’t promote collaboration.

Due to such problems, it is recommended to split the application into smaller segments or microservices which perform their specified task independent of other services. Such a setup promotes not only easy and better management but also readability and productivity. This article will discuss how we should generally structure our python applications for better management, readability, and productivity.

Project Structure for a Python Application

The idea is to split the program into smaller components or microservices. These are essentially some directories with Python files that only perform the task allotted to them. These are generally standalone files that are independent of other services. This way, it is easy to remove or add a service.

Note that some of the directories or segments mentioned may or may not apply to every application globally because some applications are straightforward and don’t require much testing and management. At the same time, some are pretty lengthy and robust and require constant attention and management.

These directories and files should be created under an empty parent project folder.

1. LICENSE: This file contains legal information about the guidelines for using the application and distribution details of the application.
2. README.md: This markdown file contains a brief description of the application, its files, guidelines to set up the application and run it, guidelines for contribution, if the application is open-source, etc.
3. setup.py or run.py: This file is the entry point for any Python application. This means that whenever we wish to run a Python application following a similar project structure, we have to execute this file simply.
4. env or environment: This is the Python virtual environment of the application.
5. requirements.txt: This text file contains information about the dependencies of the Python application.
6. /<sub-application>: This folder contains a standalone sub-application or a microservice. These folders should have an __init__.py making them Python modules. We can find such folders in Django and Flask applications in the form of applications and blueprints, respectively. Note that since these mini-applications or microservices are independent of other such applications, they can have their own /tests, /static, /templates folders and models.py, and forms.py files.
7. /docs: This folder contains the documentation of the Python application. The documentation is generally expected to be robust and comprehensive so that the end-user can understand the application without any issues.
8. /tests: This folder contains all the tests for the application. Since testing is an essential step before pushing any application to production, it should have its dedicated directory. The number of tests can rise drastically when the application or features grows.
9. /static: This folder contains all the static files of the application, such as images, videos, logos, and icons. If the project is a web application, the static folder will also contain CSS and JavaScript files. One can find this folder in Django and Flask applications.
10. /templates: This folder contains all the HTML templates used by the Python application. Generally, this folder is relevant to Python web applications because the web requires HTML. Again, we can find this folder in Django and Flask applications.
11. models.py: This file contains the Python code for database models. Python classes representing database models are defined inside this file when using an ORM or Object Relational Mapping.
12. database.db: This file is the database that the Python application uses. This file is only needed or created when the application uses a simple file-based database such as SQLite3.

An example

Suppose we are working on a web-based personal blogging website. Then the project structure of such an application will look something like this.

blog/
|-- LISCENSE
|-- README.md
|-- run.py
|-- models.py
|-- database.d
|-- environment/
    |-- * files *
|-- requirements.txt
|-- users/
    |-- __init__.py
    |-- forms.py
    |-- routes.py
    |-- * files *
|-- blogs/
    |-- __init__.py
    |-- forms.py
    |-- routes.py
    |-- * files *
|-- docs/
    |-- * files *
|-- tests/
	|--	users/
    	|-- * files *
    |-- blogs
	    |-- * files *
|-- static/
    |-- users
	    |-- * files *
    |-- blogs
	    |-- * files *
|-- templates/
    |-- users
	    |-- * files *
    |-- blogs
	    |-- * files *