The Ecosystem: pip & Virtual Environments

The first time you use someone else's Python package, the language suddenly feels much bigger. Charts, web requests, pretty terminal tables, game tools: most of Python's power lives outside the standard library, and you reach it with pip plus a virtual environment.

This workflow belongs in your terminal on your machine. The browser playground cannot install packages from the internet, so this lesson uses terminal commands instead of a runnable playground.

pip, PyPI, and external packages

An external package is a code bundle you install from outside Python's standard library. PyPI is the Python Package Index, the main online catalog where Python packages are published. pip is Python's package installer, the tool that downloads packages from PyPI and puts them into the Python environment you are using.

Use python -m pip, not plain pip, when you can. The -m flag tells Python to run a module as a command. That keeps pip tied to the exact Python interpreter your terminal is using.

Check that pip is available:

$ python -m pip --version
pip 24.x from ... (python 3.14)

→ Your version and path will differ. The important part is that it says pip and the Python version you expect.

Think of PyPI as a public tool shelf, and pip as the runner that fetches a tool from that shelf into your project workspace. The shelf is shared by everyone. Your workspace should not be.

Install, upgrade, and remove packages

Imagine a small score reporter where you want prettier terminal output. rich is a popular external package for styled terminal text. You would install it like this:

$ python -m pip install rich

After that, code running in the same environment can import rich. If you later want the newest version that pip can install from PyPI, use --upgrade:

$ python -m pip install --upgrade rich

To remove it:

$ python -m pip uninstall rich

pip will ask for confirmation before removing files. Read the package name before you press y.

A dependency is a package your project needs in order to run. Some packages also need other packages. pip handles those nested needs for you, which is convenient, but it also means your project environment can fill up quickly. That is where virtual environments matter.

Create a virtual environment

A virtual environment is an isolated Python workspace with its own package folder. venv is the standard-library module that creates virtual environments.

The habit is: one project, one virtual environment. It is like giving each project its own labeled drawer in the workshop. The score reporter gets its drawer. The snack tracker gets a different drawer. Tools do not spill between them.

From inside your project folder:

$ python -m venv .venv

.venv is the folder name. The leading dot keeps it visually tucked away on many systems, and many editors recognize it automatically.

Next, activation means changing your current terminal session so python and pip point at that virtual environment.

macOS or Linux:

$ source .venv/bin/activate
(.venv) $ python -m pip --version
pip 24.x from .../.venv/... (python 3.14)

Windows PowerShell:

PS> .\.venv\Scripts\Activate.ps1
(.venv) PS> python -m pip --version
pip 24.x from ...\.venv\... (python 3.14)

That (.venv) prompt is your visual signal. It means this terminal is using the project drawer, not your shared Python install.

When you are done:

(.venv) $ deactivate
$ 

The normal project workflow

Here is the safe pattern for a new project called score-reporter:

$ mkdir score-reporter
$ cd score-reporter
$ python -m venv .venv
$ source .venv/bin/activate
(.venv) $ python -m pip install rich

On Windows, swap the activation command for the PowerShell command shown above. The rest of the idea is the same.

Inside that activated terminal, python runs the environment's Python, and python -m pip installs into that environment. If you open a new terminal later, activate again before running project commands.

If the prompt does not show (.venv), pause. Either activate the environment or run python -m pip --version and check whether the path includes .venv.

requirements.txt makes setup repeatable

A requirements file is a plain text file listing the packages a project needs. The common filename is requirements.txt.

The strict form pins exact versions with ==:

rich==13.9.4

A reproducible setup is a setup another machine can rebuild with the same dependency versions. Pinning versions helps because "install whatever is newest today" can mean different code next month.

To install everything listed in a requirements file:

(.venv) $ python -m pip install -r requirements.txt

The -r option means "read package names from this file." The environment still matters: run that command after activating the project's .venv.

You will also see this command:

(.venv) $ python -m pip freeze > requirements.txt

Shell redirection sends command output into a file; > overwrites the target file. pip freeze prints installed packages in requirements format. It is useful, but it can include extra packages pulled in by the packages you asked for, so read the file before treating it as the project's clean contract.

For now, remember the shape:

• .venv/ is the private workspace for installed packages.
• requirements.txt is the shareable list of what the project needs.
• python -m pip install -r requirements.txt rebuilds that list in a fresh environment.

You now know the boundary between code Python ships with, code you write, and code you install. Next, you move into file handling, where your programs start keeping data outside memory.