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
requestsinstalled 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.
Run the code to see output.
This runs in an isolated Python worker in your browser. Your edits stay in this browser until you reset them.