Where you are. Eight lessons in, you hold the whole map: money is ledger entries, the ledgers sit in two tiers, banks settle in reserves on the central bank’s ledger, and the tokenisation claim proposes to rebuild that machinery around one fused object. You also know how this course marks the claims that expire. Every line of code you have run so far used Python’s standard library alone: dicts, loops, asserts, print. This lesson adds the only two third-party libraries the entire course uses, and a script that proves they work on your machine.
The whole toolbag
Think of the last data repository you cloned at work. The requirements file ran to a few hundred lines, half of them pinned to versions nobody chose on purpose, and the install died at a C compiler error inside a transitive dependency of a package the project never imports. You fixed it, eventually, with one magic environment variable found in a closed GitHub issue.
This course makes the opposite bet. Here is its complete list of third-party dependencies: numpy and matplotlib. Arrays of numbers, and pictures of them. Everything else - the ledgers, the clearing, the netting, the settlement logic - is code you will write yourself, because writing it is how the plumbing gets into your hands.
The idea in one paragraph
You will create one virtual environment for the course, install numpy and matplotlib into it, and run a checker that proves the full path works: the right interpreter, both libraries importable, and a figure actually rendered to disk. The last step matters most, because plotting is the one part of the toolchain that touches your operating system’s rendering stack, which is where setup problems like to hide. When the checker’s final line prints, your equipment for all eight modules is verified.
Build the environment
From the course root:
python3 -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install numpy matplotlibThree lines, three jobs. The first creates .venv, a private interpreter whose installed packages cannot collide with anything else your machine hosts. The second points this shell’s python and pip at it. The third installs the toolbag. If you want the install pinned on disk, pip freeze > requirements.txt records exactly what you got, so a second machine can reproduce it.
Run the checker
cd module-00-orientation/code
python check_setup.pyRead code/check_setup.py before you run it; it is short, and its order of operations is the engineering lesson. It prints the Python version and the interpreter’s location first, before attempting a single import, so that if an import fails you already know which Python tried it. It then imports numpy, forces matplotlib onto the Agg backend - a renderer that draws into memory and writes files, needing no window system, so the same script works over SSH and in CI - prints both library versions, draws a two-bar chart, and saves it as setup_check.png beside the script.
Check yourself
1. The checker prints the interpreter’s location before attempting any import. Why that order?
Because the most common setup failure is running the wrong interpreter, and an ImportError alone does not say which Python raised it. Printing the location first means every failure arrives with its diagnosis attached: the traceback tells you what broke, and the line above it tells you where. Fail fast, but log the context first.
2. What exactly does the venv warning detect, and what can it not detect?
Inside a virtual environment, sys.prefix points at the venv directory while sys.base_prefix still points at the installation the venv was created from; when the two are equal, no venv is active. That is all the check knows. It cannot tell that you activated the wrong venv, or that a library landed somewhere else entirely - those surface later, as a failed import or an unexpected version in the printout.
3. Why does the script force the Agg backend before importing pyplot?
Pyplot chooses a rendering backend at import time based on what the environment offers, and on a machine with no display a GUI backend can fail or hang. Agg renders into a memory buffer and writes image files, which is all this course ever needs: every figure you produce is a file on disk, not a window. Choosing the renderer explicitly, before the import that would choose one implicitly, is deployment configuration done in the right order.
4. Why does a whole finance course cap itself at two libraries?
Determinism and lifespan. Every exercise must run on a laptop CPU in under a minute, with no API keys and no live network calls, and each dependency added is a version surface that can drift over the years the course is in use. numpy covers the arithmetic, matplotlib covers the figures, and the finance itself - the ledgers, the netting, the settlement rules - stays standard-library code you write and read yourself.
Do this
The exercise is the setup itself; there is nothing to fill in.
python3 -m venv .venv
source .venv/bin/activate
pip install numpy matplotlib
cd module-00-orientation/code
python check_setup.pyThe final line of output must read:
wrote setup_check.png - open it; if you can see two bars, everything worksOpen the file and check the bars against the description above. If the output includes WARNING: not inside a virtual environment, stop: re-activate the venv in this shell, reinstall, and run again until the warning is gone. The script is code/check_setup.py; the copy in solutions/check_setup.py is identical, because a verifier is the one script with no TODO(you) in it.
What you can now do. You have a verified environment: the right interpreter, the only two libraries the whole course needs, and a rendered figure on disk proving the plotting path works end to end. The toolkit’s first real job comes next: lesson 10 hands you a toy two-tier ledger and one payment to push across it, and every exercise from module 1 onwards assumes exactly the environment you just proved.