Structuring Your Project Files

Even for small projects, giving some thought to how you organize your files pays off significantly. Good structure makes your code easier to understand, maintain, and share with others (or even with your future self!). When you come back to a project after a break, a logical layout helps you find things quickly.

Start with a Project Directory

The first step is always to create a dedicated directory (a folder) for your project. Avoid scattering your Python script and related files across your Desktop or Documents folder.

For instance, if you're building the simple command-line tool discussed in this chapter, create a directory for it:

mkdir my_simple_tool
cd my_simple_tool

All files related to this specific tool will live inside the my_simple_tool directory.

A Basic Structure

For a very simple application consisting of a single script, your project structure might just be the script itself and perhaps a descriptive file.

Basic project structure with a main script and a README file.

Here:

• tool.py: This is your main Python script containing the application's code. You might name it something descriptive like calculator.py or task_manager.py.
• README.md: This is a text file written in Markdown format. It's standard practice to include a README.md to explain what the project does, how to set it up (if necessary), and how to run it. Even a simple description is helpful.

Separating Concerns: Multiple Files

As your application grows slightly, you might find yourself writing helper functions or defining specific classes. Instead of putting everything into one massive script, it's often better to separate logically distinct parts into different files (modules). This improves organization and reusability.

Imagine your command-line tool needs several utility functions. You could place these in a separate file, perhaps called utils.py.

Project structure with the main script, a utility module, and a README.

In this structure:

• tool.py: Remains the main script, the entry point for your application. It would import functions or classes from utils.py.
• utils.py: Contains helper functions or classes used by tool.py.
• README.md: Still serves as the project description.

You can then import functions from utils.py into tool.py using an import statement, like import utils or from utils import specific_function.

Tracking Dependencies: requirements.txt

If your project starts using external packages (libraries you install using pip), it's essential to keep track of them. The standard way to do this is with a file named requirements.txt. This file lists the external packages and their versions needed to run the project.

Example requirements.txt:

requests==2.28.1
numpy>=1.21.0

Even if your initial project doesn't use external libraries, knowing about requirements.txt is useful for future projects or when sharing your code. Someone else can easily install all necessary dependencies using pip install -r requirements.txt.

Common Conventions for Larger Projects

As projects become significantly larger and more complex, more elaborate structures are often adopted. You might encounter directories like:

• src/ or app/: Containing the main source code of the application, often structured into further sub-packages.
• tests/: Containing code to test the main application code.
• docs/: For documentation files.
• data/: For data files used or generated by the application.
• scripts/: For utility or helper scripts related to the project.

For the simple command-line tool we're building in this course, the basic structures shown earlier are usually sufficient. The main principle is to keep things organized in a way that makes sense for the current complexity of your project, allowing it to grow logically if needed. Starting with a dedicated directory and a README.md is always a good practice. Adding separate files for distinct logic (utils.py) is the next logical step as complexity increases slightly.