One of Python's great strengths is its ecosystem: hundreds of thousands of packages ready to install and use. But installing packages haphazardly into the system Python ends, sooner or later, in version conflicts and broken projects. In this lesson you'll learn the professional solution: virtual environments (venv), which isolate each project's dependencies, and pip, Python's package manager, together with the requirements.txt file that lets you reproduce an environment on any machine. Setting this up now, even though the Papyrus project doesn't need external packages yet, will give you the right habit from day one.

1. The problem: shared dependencies and conflicts
2. What a virtual environment is
3. Creating, activating and deactivating an environment with venv
4. pip: installing, listing and uninstalling packages
5. requirements.txt: reproducible environments
6. Good practices
7. Alternatives worth knowing about: conda and poetry

Imagine this very real scenario:

• For the Papyrus project you install a reporting package, version 2.0.
• Months later, for another project, you need the same package but in version 3.0 (with incompatible changes).
• If both projects share the same Python installation, they can't coexist: upgrading breaks Papyrus; not upgrading blocks the new project.

This is colloquially called dependency hell. And it has a second front: if you install everything into the operating system's Python, you can even interfere with tools of the system itself that depend on it (some Linux distributions outright block it with an externally-managed-environment error).

The solution is conceptually simple: each project gets its own isolated copy of the Python environment, with its own packages and versions.

A virtual environment is a folder inside your project that contains:

• A copy of (or link to) the Python interpreter.
• Its own folder of installed packages, independent of the system's and of other environments'.
• Activation scripts that temporarily "redirect" the python and pip commands to that environment.

Key points to understand it well:

• It's not a virtual machine or anything heavyweight: it's basically a folder with files. Creating one takes seconds.
• While an environment is activated, everything you install with pip lands inside it, without touching anything else.
• If an environment gets broken, you delete the folder and create another one. Nothing on the system is affected.

The standard tool for creating them, venv, is included with Python 3: there's nothing to install.

Move into your project folder (the papyrus folder you created in lesson 01-02) and run:

Breaking down the command:

• python -m venv — runs the venv module that ships with Python (-m means "run this module"; you'll understand modules better in module 3 of the course).
• .venv — the name of the folder where the environment will be created. It's the most widespread conventional name (the leading dot marks it as an "internal working" folder); you'll also see venv or env.

After a few seconds you'll have a .venv folder inside the project. Don't edit anything inside it: it's tool territory.

Activating the environment means that, in that terminal, python and pip become the environment's own. The command depends on the system:

On Windows (PowerShell):

On macOS/Linux:

The unmistakable sign that it's active is the (.venv) prefix in the terminal prompt. From that moment on:

Note for Windows/PowerShell: if an error about "running scripts is disabled" appears when activating, run Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser once and try again. It's a PowerShell protection, not a Python failure.

Note for VS Code: when you open the project folder, VS Code usually detects .venv and asks whether you want to use it as the interpreter. Say yes: that way the editor and its integrated terminal will use the environment automatically. If it doesn't ask, press Ctrl+Shift+P → "Python: Select Interpreter" and choose the one in .venv.

To go back to the system Python in that terminal:

The prefix disappears. The environment is not deleted: it just stops being active. The next time you work on the project, you activate it again. And if some day you want to truly remove it, just delete the .venv folder.

The daily work cycle, summarized:

pip is Python's package manager: it downloads packages from the official PyPI repository (Python Package Index, https://pypi.org, with hundreds of thousands of published packages) and installs them into the active environment.

With the .venv environment activated, the essential commands:

(cowsay is a joke package, perfect for practicing risk-free: it makes a text-art cow "say" things.) pip downloads the package and its dependencies and installs them into .venv. Let's try it:

The import statement (which you'll study in depth in module 3) is how you use an installed package from your code.

You can also install a specific version, something key for reproducibility:

And for the details of a specific package (version, summary, dependencies):

pip freeze is like pip list, but in "reinstallable" format (package==version). It's the basis for the requirements.txt coming up next.

pip will ask for confirmation (y) and remove the package from the environment.

Imagine you share the Papyrus project with someone else (or with your own computer a year from now). The .venv folder is not shared (it's heavy and machine-specific); what you share is the dependency list: the requirements.txt file.

With the environment activated and the packages you use installed:

The > symbol redirects the command's output into the file. The result is a text file at the project root:

Each line is a package with its exact ("frozen") version: the guarantee that another environment will install exactly the same thing.

Whoever receives the project (or you yourself on another machine) only needs:

The -r option means "install everything this file lists". In three commands, an environment identical to the original.

Keep requirements.txt up to date: every time you install or uninstall a package relevant to the project, run pip freeze > requirements.txt again.

• One virtual environment per project, always. Even if the project is small. Creating a .venv takes 10 seconds; untangling a version mess takes entire afternoons.
• Don't install packages into the system Python. The "global" Python should stay clean, used only for creating environments. If you ever run pip install and don't see (.venv) in the prompt, stop and activate the environment.
• The environment folder is called .venv and lives at the project root. It's the convention that tools (VS Code included) detect automatically.
• requirements.txt is shared; .venv is not. If you use git, add .venv/ to the project's .gitignore so it doesn't get pushed to the repository.
• Don't edit anything inside .venv. It's regenerated, not repaired: whenever anything strange happens, delete the folder and recreate it from requirements.txt.
• Check where you're installing. pip --version shows the path of the active pip; if it points inside your project, all is well.
• Pin versions in serious projects. pip freeze with == guarantees the project will work the same six months from now, even if the packages have published new versions.

venv + pip is the standard kit and it's all you need in this course. But in the real world you'll hear about other tools, and it's worth having heard of them:

We won't study them in this course: everything we do works with venv and pip. If a team or tutorial later uses conda or poetry, the concepts you've just learned (isolated environment, dependency list, pinned versions) are exactly the same; only the commands change.

• Installing without activating the environment: the most frequent mistake. The package ends up in the system Python and your project "mysteriously" can't find it (or the other way round). Always look for the (.venv) prefix before a pip install.
• Opening a new terminal and forgetting to reactivate: activation is per terminal and per session. New (or restarted) terminal = activate again.
• ModuleNotFoundError: No module named '...' when running your script: it almost always means the package is installed in another environment (or in none), or that VS Code is using an interpreter other than your .venv's. Check "Python: Select Interpreter".
• A "running scripts is disabled" error in PowerShell: apply the Set-ExecutionPolicy given in the activation section; it's a PowerShell thing, not your installation.
• Pushing .venv to git or emailing it: it's heavy and useless outside your machine. requirements.txt is what's portable.
• Renaming or moving the .venv folder: environments contain internal absolute paths and stop working. If you need to move one: delete and recreate (with requirements.txt it's two commands).
• Tip: create the environment for your papyrus folder now and activate it every time you work on the course, even if you barely install anything for the moment. When we install Flask, pandas and friends in modules 10 and 11, the habit will already be in place.

In your project's papyrus folder: create a virtual environment called .venv, activate it, check with pip list that it's (almost) empty and deactivate it. Note down the exact commands you used on your operating system.

With the Papyrus environment activated: install the cowsay package, check with pip show cowsay which version you have, generate the project's requirements.txt and display its contents in the terminal.

Simulate "handing over" the project: deactivate and delete the entire .venv folder (relax: that's what the exercise is for), and rebuild the environment from scratch using only requirements.txt. Finish by checking with pip list that cowsay got installed again.

Solution 1

On Windows (PowerShell):

On macOS/Linux:

pip list in a freshly created environment shows only pip (and in some versions, setuptools): that's the proof that the environment is clean and isolated.

Solution 2

With (.venv) visible in the prompt:

To view the file's contents: type requirements.txt on Windows or cat requirements.txt on macOS/Linux. It should contain something like:

Solution 3

Deleting the folder: Remove-Item -Recurse -Force .venv in PowerShell (or delete it from the file explorer), rm -rf .venv on macOS/Linux. Then, the rebuild:

pip list shows cowsay again, in the exact version recorded in requirements.txt. You've just demonstrated the lesson's central idea: the environment is disposable; the dependency list is what's valuable.

With this lesson you close the introductory module equipped like a professional: you know why dependencies are isolated, you create and manage environments with venv (create, activate per system, deactivate), you handle pip (install, list, show, freeze, uninstall) and you make your projects reproducible with requirements.txt, following the good practices of one environment per project and an always-clean system Python. You've also heard of conda and poetry, the alternatives you'll come across out there.

The Papyrus project now has everything it needs: a complete development environment, its first scripts (welcome, catalog, interactive book card) and a virtual environment ready to grow. In the next module, Control Structures, your programs will start making decisions and repeating tasks: conditionals to know whether something is in stock, loops to walk through the entire catalog, and much more. That's where programming starts to feel like a superpower.