4. Virtual environments

Virtual environments are the most important part of your development setup. They prevent the dependency conflicts that plague beginners and cause mysterious "it worked yesterday" problems. Every Python project should have its own.

This isolates each project's libraries from your system Python and from other projects. It's a best practice that professional developers follow religiously, and you're going to adopt it from day one.

Creating your first virtual environment

Make sure you're in your api-projects folder (if not, use cd ~/api-projects or cd %USERPROFILE%\api-projects). Then create your first virtual environment:

python -m venv my-first-api-env

python3 -m venv my-first-api-env

This command creates a new folder called my-first-api-env that contains a complete, isolated Python installation. It usually takes a few seconds to complete. You won't see any output unless there's an error.

• python -m venv. Run Python's built-in virtual environment module
• my-first-api-env. Name of the folder to create (you can use any name)

The -m flag tells Python to run a module as a script. In this case, we're running the venv module, which comes built into Python 3.3+.

Activating your virtual environment

Creating the virtual environment isn't enough. You need to activate it. Think of activation as "turning on" your isolated Python workspace. When activated, any packages you install go into this environment instead of your system Python.

my-first-api-env\Scripts\activate

source my-first-api-env/bin/activate

After activation, you'll see the environment name in parentheses at the start of your command prompt:

(my-first-api-env) C:\Users\YourName\api-projects>

(my-first-api-env) YourName@computer:~/api-projects$

That (my-first-api-env) prefix is your visual confirmation that the environment is active. Always look for this before installing packages or running Python code. If you don't see it, your environment isn't active.

Critical habit to develop

Activate your virtual environment before working on a project. This is the single most important habit for avoiding dependency issues. Every time you open a new terminal window to work on your API projects, you need to:

1. Navigate to your projects folder: cd %USERPROFILE%\api-projects on Windows, or cd ~/api-projects on macOS/Linux
2. Activate the environment: my-first-api-env\Scripts\activate on Windows, or source my-first-api-env/bin/activate on macOS/Linux
3. Verify activation by checking for the (my-first-api-env) prefix

Make this your ritual. Open terminal → navigate → activate → verify. Do it so many times it becomes automatic.

The daily workflow

Here's what your typical work session will look like:

# 1. Navigate to your projects folder
# Windows:
cd %USERPROFILE%\api-projects

# macOS/Linux:
cd ~/api-projects

# 2. Activate your virtual environment  
# Windows:
my-first-api-env\Scripts\activate

# macOS/Linux:
source my-first-api-env/bin/activate

# 3. Now you're ready to work
# - Install packages with pip
# - Run Python scripts
# - Work on your projects

# 4. When finished, deactivate (optional)
deactivate

The deactivate command returns you to your system Python. However, it's perfectly fine to leave your virtual environment active. Many developers keep it active all day while working on a project.

Understanding deactivation

When you're done working, you can deactivate your virtual environment:

deactivate

The (my-first-api-env) prefix disappears, and you're back to using your system Python. Closing your terminal window also deactivates the environment automatically. The next time you open a terminal, you'll need to activate again.

Many developers never manually deactivate. They simply close the terminal when done or keep the environment active while working on the project. Either approach is fine.

Next, you'll install the requests library inside this environment and set up an editor for writing Python files.