Virtual Environments And Package Management

So far, we stayed inside Python itself. We either wrote our own code or used modules that come with every Python installation, like json, pathlib and random. But a huge number of people write Python, and many of them share their code as packages that anyone can install. Packages that come from outside Python’s standard library are called 3rd party packages.

This section of the tutorial explains how to install those packages without making a mess of your system. It covers virtual environments, the pip package installer, the newer all-in-one tool uv, and a few other tools you’ll run into.

What is a 3rd party package?

If you followed this tutorial, you already know how to create your own Python packages to organize code in directories. A 3rd party package is the same idea, built so it can be shared. Most of them are published on the Python Package Index at PyPI.org, which lists more than 900,000 projects as of November 2026. Popular examples are requests for HTTP, pandas for working with tables of data, and pytest for testing.

Installing one is a single command, such as python -m pip install requests. The question is where that package ends up, and that’s where virtual environments come in.

What is a virtual environment?

A virtual environment, or venv, is a folder that holds its own set of installed packages, separate from the rest of your system. When you activate it, python and pip use that folder. Each project gets its own venv, usually in a folder called .venv inside the project.

Why bother? A few reasons:

• Two projects can need different versions of the same package. With a venv per project, they don’t get in each other’s way.
• You can write down exactly what a project needs and recreate the environment on another computer, or on a server.
• Your operating system’s own Python stays untouched. Many Linux distributions, and Homebrew on macOS, now refuse a plain pip install outside a venv and show an externally-managed-environment error. A venv is the fix.
• When something goes wrong, you delete the .venv folder and create a fresh one. Nothing else on your system is affected.

What’s in this section

Read the first three in order. They build on each other: first the venv, then pip to fill it, then uv, which does both jobs faster and adds a lot more.

1. Python venv: create, activate, deactivate and delete a virtual environment with the venv module that ships with Python.
2. Pip install: install, upgrade and remove packages, use a requirements.txt file, and fix the externally-managed-environment error.
3. Python uv: one fast tool for venvs, packages, lock files and Python versions, and how it compares to pip, venv and Poetry.

The other pages cover tools you may meet in existing projects or need for a specific job:

• Poetry manages dependencies, the venv and packaging for a project. Plenty of projects still use it.
• Pipenv combines pip and venv with a Pipfile. You’ll mostly see it in older projects.
• Pipx installs command-line tools written in Python, each in its own venv.
• PyEnv installs and switches between several Python versions.

Not sure where to start? Use a plain venv and pip while you learn what each piece does. Once that feels familiar, switch to uv for your own projects.

Practice it in your browser

The chapter Isolated Environments and Packages in our Python in Practice course covers the same ground with a real terminal in the browser. The first lesson, One Python, many projects, is free and shows the problem a venv solves before you set one up yourself.