Discussion on "Packaging & Environments: Modules, Virtual Environments, and pyproject.toml"

ZyVOP · 2026-10-23T06:13:30.347Z

Every programmer eventually says the same sentence: "But it works on my machine." Usually it means two computers have different versions of Python, or different libraries installed, or both. This post

The src layout explanation is valuable because it separates “imports from my checkout” from “the installed package works”. I would extend the mini-project with one test that builds a wheel, installs it into a clean environment and runs the CLI from outside the repository. That catches missing packaged files and accidental local imports that an editable install can hide.

Great suggestion! An editable install can hide packaging issues that only show up when the project is installed as a proper distribution. Building a wheel, installing it in a clean environment, and running the CLI from outside the repository is an excellent way to catch missing files and accidental local imports. I’ll consider adding this as a follow-up exercise. Thanks for the valuable feedback!

The "works on my machine" sentence almost always traces back to a missing environment boundary, and one venv per project plus pyproject.toml is what turns the fix into something the next person can reproduce. The import * warning deserves its own line: losing track of where a name came from costs real debugging time.

Absolutely! Reproducibility starts with making the environment explicit, not just documenting how to set it up. A project-specific venv and pyproject.toml reduce environment drift, while avoiding import * keeps dependencies clear and debugging much easier. Small practices that save a lot of time as projects grow.

Search Hashnode

Packaging & Environments: Modules, Virtual Environments, and pyproject.toml

Responses4