Creating Isolated Python Environments and Pinning Dependencies

Hello! This course starts with the working habits that make Python projects reliable, then builds toward data work, machine learning, and AI applications. Today you’ll set up one project so its packages stay separate from other projects—and so you can recreate its package versions later. Plan on about 40 minutes, with most of that time spent trying the commands yourself.

---

Why give a project its own environment?

Suppose two projects need different versions of the same library. If both use one shared Python installation, changing the library for one project can disrupt the other. A virtual environment gives each project its own place to install packages. Creating one does not install every package you will need; it gives you a clean starting point.

Watch the first part of Tech With Tim’s Python Virtual Environments - Full Tutorial for Beginners. The presenter names his environment env; we’ll use .venv, a common name that makes its purpose clear.

Activation changes which Python and package installer your terminal uses. That is useful, but the prompt alone is not the strongest check: you can ask Python where its executable lives.

---

Create and inspect your environment

Open a terminal in a place where you want to keep the project. First make a project directory and enter it:

mkdir ai-workflows
cd ai-workflows

You need Python 3 installed before continuing. Check with python3 --version on macOS/Linux, or py -3 --version on Windows. Then create the environment inside ai-workflows:

System	Create the environment	Activate it
macOS/Linux, bash or zsh	python3 -m venv .venv	source .venv/bin/activate
Windows Command Prompt	py -3 -m venv .venv	.venv\Scripts\activate.bat
Windows PowerShell	py -3 -m venv .venv	.\.venv\Scripts\Activate.ps1

If py is unavailable on Windows but python --version works, use python -m venv .venv to create it. If PowerShell blocks its activation script, using Command Prompt is a straightforward alternative.

Now run these commands in the activated terminal:

python --version
python -c "import sys; print(sys.executable)"
python -m pip list

The executable path should contain ai-workflows and .venv. That is better evidence of which Python you are using than the prompt decoration. Record the reported Python version in your project notes: a package list alone does not specify the Python interpreter version.

The .venv directory holds generated environment files, not your application code. Keep code and project files alongside it, rather than inside it. Create a .gitignore file in ai-workflows with these lines:

.venv/
.venv-check/

This will keep both the working environment and a temporary verification environment out of version control when you use Git later. The dependency file you create next is the file to keep.

---

Install a package and pin the result

We’ll install requests, a library you can use when this course reaches REST APIs. Run:

python -m pip install requests
python -c "import requests; print(requests.__version__)"

Using python -m pip ties the installer to the Python you just checked. The installation may include packages other than requests: those are its transitive dependencies, packages it needs in order to work.

Before recording versions, watch how the video exports and then restores a package set:

For an authoritative reference, read the relevant parts of the Python Packaging User Guide. Its explanation of environments clarifies what activation does; its requirements-file sections explain what is saved and reinstalled. You can skip its unrelated package-upgrade discussion for now.

Back in your activated ai-workflows environment, create the dependency file:

python -m pip freeze > requirements.txt

Open requirements.txt in a text editor. You should see entries in the form package-name==version, including requests and likely several of its dependencies. Pinning means recording exact versions rather than leaving the choice open to whatever version is newest on a future installation. Keep requirements.txt with your project; do not copy the .venv directory to share the setup.

A freeze records what is installed, not which packages you intentionally chose. That is why it is best to start with a clean environment and install only what this project needs before freezing. Whenever you deliberately change its package set, generate and review the file again.

---

Check that the project can be rebuilt

A useful test of requirements.txt is whether it works without relying on the environment you have already set up. First, leave that environment:

deactivate

Create a second environment in the same project directory, named .venv-check. Use the creation command for your system, substituting .venv-check for .venv, then activate it using the corresponding activation command with the same substitution. For example, on macOS/Linux:

python3 -m venv .venv-check
source .venv-check/bin/activate

On Windows Command Prompt, the commands are:

py -3 -m venv .venv-check
.venv-check\Scripts\activate.bat

On Windows PowerShell, activate the newly created environment with .\.venv-check\Scripts\Activate.ps1. If you used python rather than py -3 to create the first Windows environment, use python again here.

With .venv-check active, install from the file in your project directory and verify the result:

python -m pip install -r requirements.txt
python -m pip check
python -c "import requests; print(requests.__version__)"

pip check checks whether installed packages report incompatible or missing dependencies. The import command confirms that this fresh environment can use requests. Compare the printed version with the requests entry in requirements.txt. You can then run deactivate; .venv-check was only a rebuild test and can be removed when you no longer need it.

Exact package versions make a project substantially easier to recreate, but they are not a guarantee of identical behavior on every machine. The Python version and operating system can also matter. For now, keeping the pinned file and a note of your Python version gives you a sound, inspectable starting point.

---

Takeaways

You created an isolated .venv, checked which Python it uses, installed a package into it, pinned installed package versions in requirements.txt, and tested that the file can populate a fresh environment. The key distinction is that the environment is disposable; the project files and its dependency record are worth keeping.

Next, you’ll organize Python code into importable modules and reusable functions—code that can run within the environment you have just prepared.