Python .gitignore template

__pycache__ and the *.py[cod] pattern cover compiled bytecode. The interpreter writes it automatically the first time it imports a module, and it is both version specific and implementation specific: bytecode produced by one interpreter version will not be loaded by another. It is regenerated on demand, so a committed .pyc is pure noise that produces spurious conflicts on every branch.

The virtual environment rules matter more. A committed venv, .venv or env directory bundles hundreds of megabytes of installed packages plus scripts with the absolute path of the machine that created them baked into their shebang lines and activation scripts. It will not work anywhere else. The requirements file or project metadata is what makes the environment reproducible, and that is what belongs in the repository.

The packaging block covers build, dist, sdist, wheels, eggs, develop-eggs and *.egg-info. These are what the build backend produces on its way to a distributable archive. They are derived entirely from your sources and the project configuration, and republishing from a stale committed copy is a real way to ship the wrong code.

Testing and typing tools each keep their own cache in the tree: .pytest_cache, .tox, .nox, .hypothesis, .mypy_cache, .ruff_cache and .pytype, along with the coverage outputs .coverage, htmlcov and coverage.xml. None of it is portable and all of it is regenerated. The .env rule here is the important one for secrets, since a Python project keeps its database URL and API keys there by convention.

One rule deserves suspicion. lib/ and lib64/ exist because older packaging layouts wrote there, but the pattern is not anchored, so a project with its own source package named lib will find that package silently ignored. If your imports work locally but a fresh clone cannot find a module, this is the first rule to check.