Unit 11 · lesson

Where Did That Import Come From?

Core path: 30 minutes

import requests looks like one line.

Underneath that line is a whole environment question:

Which Python interpreter is running, where does it search for packages, and is requests installed in that environment?

If you skip those questions, package problems feel random. They are not random. The runtime is searching specific locations according to specific rules.

Importing is not installing

This:

import requests

asks the running Python interpreter to find a module/package named requests.

This:

python -m pip install requests

asks the pip associated with that Python command to install the package into that environment.

Those are different operations.

A common mistake is treating the import statement like a download request. It is not.

Ask Python which interpreter is running

Run:

python -c "import sys; print(sys.executable)"

Then:

python -m pip --version

Look at the paths in both outputs.

The goal is to prove that the interpreter and the package installer belong to the environment you think you are using.

This is why I prefer:

python -m pip ...

over blindly typing:

pip ...

The first form makes the relationship to the selected Python interpreter more explicit.

Rebuild from a clean environment

Your .venv is supposed to be replaceable.

That means the project should survive this thought experiment:

source code stays
requirements.txt stays
.venv disappears

Could another developer recreate the environment?

A simple workflow is:

python -m venv .venv
# select/activate environment
python -m pip install -r requirements.txt

Then verify:

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

If the project only works because your machine has mystery packages installed globally, the environment is not reproducible.

Package versions are part of evidence

A dependency name alone may not explain the exact environment used during testing.

Inspect:

python -m pip show requests

or:

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

Record the version you actually tested.

You do not need to pin every beginner project to an exact dependency graph this week. You do need to understand that "requests is installed" and "requests version X was tested" are different claims.

Standard library versus third-party package

These imports usually work without pip because they are part of Python's standard library:

import json
import csv
import pathlib
import random

This one is normally third-party:

import requests

So when import json works but import requests fails, do not assume Python's entire import system is broken.

Ask which layer the missing module belongs to.

Your own modules live in the project too

If your project contains:

main.py
storage.py
systems.py

then:

from storage import load_systems

is importing code from your project.

Now you have three different sources of imported code:

YOUR PROJECT MODULES
storage.py, systems.py

PYTHON STANDARD LIBRARY
json, pathlib, random

THIRD-PARTY PACKAGES
requests

Same import syntax family. Different source layers.

That distinction is worth making visible.

Create one controlled failure

Use the project environment from Lesson 4.

Temporarily select a Python interpreter that does not have the project's dependency installed, if your classroom setup safely allows it.

Or, if changing interpreters would create unnecessary risk, reason from supplied evidence instead.

Try:

import requests

Record the failure.

Then return to the correct project environment and verify the import succeeds.

The source file did not change.

The environment did.

That is the lesson.

Build an environment evidence card

Record:

Project interpreter:
Python version:
Python executable path:
pip path/version:
Third-party dependency:
Dependency version tested:
requirements.txt contains:
.venv tracked by Git? yes/no
Why:

Then answer one final question:

If I clone this project onto another machine tomorrow, what information in the repository tells me how to rebuild the Python environment?

If your answer is "my memory," the project is not ready for another developer yet.

Reader workbench

Inspect a standard-library module boundary

This is the Unit's one-file practice surface. Read the code, predict one result, run it, then change a value, input, condition, or boundary and explain why the evidence changed. Multi-file projects, Git, terminals, packages, and live services still belong in the full development workspace.

unit11_practice.py
OutputRun with button or Ctrl/Cmd+Enter
Run the code to see output.
Ready to edit. Press Run when you want evidence.

This runs in an isolated Python worker in your browser. Your edits stay in this browser until you reset them.