Virtual Environments and Dependencies

Installing every package globally makes projects compete over versions and hides undeclared requirements. venv creates an environment directory that should not be committed. The source and dependency declaration belong in version control.

The central idea in this lesson is project environments. Read the rule, predict a concrete outcome, and then run the smallest example that can confirm or reject the prediction. This separates knowledge from familiarity with syntax.

Applications often pin a resolved environment for repeatable deployment; libraries usually declare compatible ranges because they must coexist with consumer dependencies. Tools such as pip-tools, uv, Poetry, or PDM can manage resolution, but understand the environment model beneath them.

from importlib.metadata import version

print("Python project checklist:")
for item in ["isolated environment", "declared dependencies", "repeatable tests"]:
  print(f"- {item}")
print("pip version:", version("pip"))

Trace the example before running it. Identify each input, transformation, returned value, and side effect. Then change one boundary value and explain why the new behavior follows from the rule rather than memorizing the output.

Do not commit credentials, .env files containing secrets, or the virtual environment directory. Avoid importing a local file whose name shadows a standard-library or third-party module. Recreate the environment periodically to prove setup instructions work.

Turn the concept into a repeatable workflow: write down the expected behavior, implement one coherent change, run a representative example, and retain a regression check. If the result surprises you, capture the exact input and error before changing anything.

Review the program for names, boundaries, and hidden side effects. A solution is complete when another developer can understand its contract, reproduce its setup, and verify both the successful path and one meaningful failure path.