Frame the project virtualenv experiment

Success is not “I followed the tutorial.” Success is producing evidence that: activated venv imports pandas at a recorded version while a second project stays untouched. The accepted input is narrow on purpose: Python 3.x, project directory, and a requirements snippet. That narrowness is what lets you inspect every field and prevents a toy demo from being narrated as a production system.

Record the baseline you must beat: record global site-packages pandas version (or absence) before creating the venv. If the finished artifact cannot beat that baseline on the fixture below, stop and revise the claim before writing more code.

printf 'pandas==2.2.2\n' > requirements.txt
python3 -c "print({'project':'lab-env','pin':'pandas==2.2.2'})"

Expected evidence: project pin recorded. Treat the printout as a claim about this fixture, not as proof that the toolchain merely started.

For the isolated project venv with pinned pandas, a decorative win often looks like a clean run that never checks which python points inside .venv; importlib.metadata.version('pandas') matches pin. Write the metric down now so later pages cannot redefine success after the fact. Also note the operational threat you will eventually gate on: pip installing from an unpinned URL or committing .venv with credentials.

For python-virtual-environments, write the claim on a sticky note in this exact shape: “Given Python 3.x, project directory, and a requirements snippet, the project virtualenv will …”. Fill the ellipsis with the observable part of: activated venv imports pandas at a recorded version while a second project stays untouched. Tape the baseline beside it: record global site-packages pandas version (or absence) before creating the venv. If someone later replaces your metric with a vibe check, the sticky note is how you push back.

Also sketch the one-sentence user story: a person uses this output to install project packages without mutating the global interpreter. If that sentence needs a dashboard, a model zoo, or five services, the lab scope is too wide—shrink the fixture (project dir lab-env/ with requirements.txt containing pandas==2.2.2) until the story fits on one screen.

Decide now whether live network calls are allowed on page 1. For this lab they usually are not; inventory and contracts should run offline against project dir lab-env/ with requirements.txt containing pandas==2.2.2. Note the metric you will eventually require (which python points inside .venv; importlib.metadata.version('pandas') matches pin) so page 4 cannot invent a softer target. The characteristic failure to keep in mind is pip installing into the system Python, or activating the wrong venv.

At the experiment brief stage for python-virtual-environments, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about project dir lab-env/ with requirements.txt containing pandas==2.2.2 that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: record global site-packages pandas version (or absence) before creating the venv.

For this page specifically, success looks like a falsifiable claim and baseline written before coding while still centering the user decision to install project packages without mutating the global interpreter. If you cannot point to a file, command, or assertion that proves that for the project virtualenv, stay on this page instead of advancing.

Set up a virtual environment

Next