---

Intro

Deploying Python applications can be done in several ways, each with trade-offs. Here, we compare three common approaches:

1. Deploying Source Code with PYTHONPATH or Package Repositories (Wheel Files)
2. Building Binaries with PyInstaller
3. Containerization (Docker) as an Alternative Approach

---

1. Deploying Source Code or Using Package Repositories

Option A: Deploying Source Code with PYTHONPATH

This approach involves copying the source code to the target machine and using PYTHONPATH to ensure Python finds it.

✅ Pros:

• Fast iteration – Modify code and restart without reinstalling.
• Easy debugging – Source is available for direct fixes.
• Good for internal tools – Especially in controlled environments.

❌ Cons:

• Dependency conflicts – Managing multiple versions can be tricky.
• Not structured for production – Harder to track versions reliably.
• Risk of accidental modifications – Unintended changes can break the app.

Example: Deploying Source Code with PYTHONPATH

1. Structure the project:
   • myproject/
     • mypackage/
       • _init__.py
       • main.py
       • run.py
2. Set PYTHONPATH and run the app:
   • export PYTHONPATH=/path/to/myproject
   • python run.py
3. Alternative: Use a Virtual Environment:
   • python -m venv venv
   • source venv/bin/activate
   • pip install <package>

---

Option B: Using a Private Wheel (WHL) Repository

Instead of deploying raw source code, build and distribute .whl files using pip or Poetry, stored in a private repository.

✅ Pros:

• More structured deployment – Ensures version control.
• Better dependency management – Works well with virtual environments.
• Faster installation – Prebuilt wheels don’t require compilation.

❌ Cons:

• Requires infrastructure – Needs an internal package index or simple HTTP server.
• Extra build step – Developers must build and publish wheels.

Example: Using a WHL Repository

1. Build a Wheel

From the source directory (myproject):

pip install build
python -m build

This creates a .whl file in dist/.

2. Host the Wheels in a Repository

A simple HTTP server can be used to store wheels:

mkdir -p /srv/pypackages
mv dist/*.whl /srv/pypackages/
cd /srv/pypackages
python -m http.server 8080

3. Configure pip to Use the Local Repo

On client machines:

pip install --index-url http://yourserver:8080/ mypackage

4. Configure Poetry to Use the Repo

poetry config repositories.myrepo http://yourserver:8080/
poetry add --source myrepo mypackage

---

2. Building Binaries with PyInstaller

PyInstaller converts a Python script into a standalone binary, so the target machine doesn’t need Python installed.

✅ Pros:

• No dependencies needed – The entire Python runtime is included.
• Easy distribution – No virtual environments or pip required.
• More secure – Source code isn’t exposed.

❌ Cons:

• Large binaries – Can be hundreds of MB.
• Harder to update – Must rebuild and redistribute binaries.
• Platform limitations – You must build on the same OS as the deployment target.

Example: Creating a PyInstaller Binary

1. Install PyInstaller: pip install pyinstaller
2. Generate an Executable: pyinstaller --onefile myproject/main.py
3. Distribute the Binary: The binary is created in dist/main (or dist/main.exe on Windows).
4. Run It Without Python: ./dist/main

---

3. Containerization with Docker

Instead of worrying about dependencies and environments, Docker packages everything (code, Python runtime, dependencies) into a container.

✅ Pros:

• Reproducible deployments – Runs the same everywhere.
• Isolated environment – No dependency conflicts.
• Scalability – Works well with CI/CD and cloud platforms.

❌ Cons:

• More overhead – Docker containers use more disk space.
• Requires Docker – The target system must have Docker installed.

Example: Dockerizing a Python App

1. Create a Dockerfile: FROM python:3.12 WORKDIR /app COPY . . RUN pip install -r requirements.txt CMD ["python", "main.py"]
2. Build and Run the Container: docker build -t myapp . docker run myapp
3. Run on Another Machine: Push the image to a registry (like Docker Hub or a private registry): docker push myrepo/myapp Then install on another machine: docker run myrepo/myapp

---

Which Should You Use?

Method	Best For	Pros	Cons
PYTHONPATH + Source	Development, fast iteration	Quick to modify, easy to debug	Not structured, risk of dependency issues
WHL Repository	Production package deployment	Controlled releases, good dependency mgmt	Requires a package repository
PyInstaller	Standalone executables	No dependencies needed, secure	Large files, hard to update
Docker	Scalable apps, CI/CD	Fully isolated, reproducible environments	More complex setup, requires Docker

Final Thoughts

• Use WHL repositories for structured production deployments.
• Use PyInstaller if you need a single-file binary.
• Use Docker for scalable, isolated environments.
• Use PYTHONPATH/source code for development only.