How to properly structure internal scripts in a Python project?

Best practice? Put a single entry-point in the root

I know this might sound absurd, if you have lots of scripts you want to be able to execute... But it's actually the cleanest option and it's the one that is most often used in big Python projects like magage.py in Django, for example. It also doesn't need to be a huge undertaking. Even more importantly, it is always more secure to have a single entry point than several smaller ones.

proj/
├── run.py
├── foo
│   └── __init__.py
├── README.md
└── scripts
    └── my_script.py

When run.py lives in the root directory, it can be very lightweight... Basically just a wrapper to call the function you need from my_scripts.py. It just ties everything together so now all of your imports just work.

Just keep in mind that your entrypoint is your root. The parent of a root doesn't exist. So put your entrypoint in the root, and then import packages relative to the root, aka import foo from scripts.

But how do I call multiple scripts!?

If you need to be able to call multiple scripts, this is a good argument for... Well... arguments! Keep run.py as your single entrypoint/command, and leverage subcommands to pass functionality to the script you care about.

Reinventing the wheel?

Generally, frameworks have already done the architecture for you to add your own subcommands, such as Django and, for a smaller footprint, Flask.

You can easily wrap up a small project without that help, though, as I've illustrated.

Security

No one ever wishes their code was less refactorable after a few years of working with it. No one ever wishes their codebase has less security. As we drive to more secure systems in general, it would make sense to create some gatekeeper script that determines what is and isn’t a safe operation and by whom. Moving the code to an LDAP based system, and need to lock things down by group? No problem. You can either change the single file or add LDAP security in your codebase, even creating your own internal API.

With distributed scripts, security options are much less flexible and much harder to maintain, and a single vulnerability could leave you wide open to exploit.

Bonus advantage You're adding abstraction to your script base. If you ever want to change the structure of your codebase (maybe you want scripts to have subfolders with more organization), you/your users don't need to do any refactoring for any dependencies, or change paths to longer, more verbose names. Your package is self-contained, and the only thing a user will ever need to touch is your proj/run.py entry-point.

And, obviously, you don't need to play with Python paths as much!

There's two ways you could resolve this.

(1) Turn your project into an installable package

Add a proj/setup.py file with the following contents:

import setuptools

setuptools.setup(
    name="my-project",
    version="1.0.0",
    author="You",
    author_email="[email protected]",
    description="This is my project",
    packages=["foo"],
)

create a virtualenv:

python3 -m venv virtualenv  # this creates a directory "virtualenv" in your project
source ./virtualenv/bin/activate  # this switches you into the new environment
python setup.py develop  # this places your "foo" package in the environment

inside the virtualenv, foo behaves as an installed package and is importable via import foo.

So you can use absolute imports in your scripts.

To make them run from anywhere, without needing to activate the virtualenv, you can then specify the path as a shebang.

In scripts/run.py (the first line is important):

#!/path/to/proj/virtualenv/bin/python

import foo

print(foo.callfunc())

(2) Make the scripts part of the foo package

Instead of a separate subdirectory scripts, make a subpackage. In proj/foo/commands/run.py:

from .. import callfunc()

def main():
    print(callfunc())

if __name__ == "__main__":
    main()

Then execute the script from the top-level proj/ directory with:

python -m foo.commands.run

If you combine this with (1) and install your package, you can then run python -m foo.commands.run from anywhere.

Solution

There are multiple ways to achieve this. Both require creating a python package by adding a setup.py (building on @matejcik's answer).

Option 1 (recommended): entry_point + console_scripts register a function in your project as the entry point to script execution (ie: proj:foo:cli:run).

Option 2: scripts: Use this keyword argument in the setup() method to reference the path to your script (ie: `bin/script.py).

Note

I recommend using a CLI library/framework like Click so that your codebase is only concerned with maintaining application specific business logic rather than CLI robust framework feature logic. Also, click recommends using entry_point + console_scripts method of script integration due to cross-platform compatibility.

Setup Tools - Automatic script creation: https://setuptools.readthedocs.io/en/latest/setuptools.html#automatic-script-creation

Setup Tools - keyword arguments: https://setuptools.readthedocs.io/en/latest/setuptools.html#new-and-changed-setup-keywords

Click GitHub: https://github.com/pallets/click/

Click Setuptools integration: https://click.palletsprojects.com/en/master/setuptools/

You need to add __init__.py files to scripts and to proj folders for those to be considered Python packages and for you to be able to import from those.

One way this is also commonly done, is to place your foo and scripts folders into a proj/src folder, which then has a __init__.py file, and thus is a Python package.