0.1 Set up your machine

Describes the Python tooling landscape as of August 2026

What this is and why it exists

Most people who quit machine learning quit in week one, fighting their own computer — a Python that will not run, packages that break each other, a notebook that cannot find anything. This topic exists to spend that pain once, properly, so it never returns: an isolated environment per project, an editor that understands Python, and one notebook run end to end.

The vocabulary

  • Python 3.12 — the interpreter itself; the version matters because libraries publish against specific versions.
  • Package manager — the tool that installs libraries and their dependencies: uv (fast, modern) or conda (older, ships scientific builds).
  • Virtual environment — a private set of installed packages for ONE project, isolated from the system and from every other project.
  • VS Code — the editor; its Python and Jupyter extensions add running, debugging and notebooks inside it.
  • Notebook (.ipynb) — a document of runnable cells mixing code, output and prose; the native habitat of exploratory ML work.
  • Kernel — the Python process a notebook's cells actually run in; "select kernel" means "choose which environment executes this".

The mental model

A virtual environment is a separate toolbox per job. Install everything into one system-wide Python and the toolbox becomes a junk drawer: project A needs one version of a library, project B another, and upgrading for B silently breaks A — the infamous dependency hell, and the single most common reason a months-old project no longer runs. One environment per project, always, means each project's tools stay exactly as it left them. The habit costs one command at project start and repays it for years.

The working setup is three layers that must point at each other: Python installed; an environment created from it per project (with uv or conda); VS Code told — bottom-right corner, or the notebook's kernel picker — WHICH environment to run. Nine of ten "module not found" errors are the layers pointing at different places: the package went into one environment while the notebook runs another. When it happens, check the kernel first, not the install.

The end-to-end notebook run is the proof of setup: create a project folder, create its environment, install two packages (numpy, matplotlib), open a notebook, select the environment's kernel, and run a cell that imports both and draws one plot. When the plot renders, every layer is aligned — and that is the moment setup is DONE, a word week-one quitters never get to say.

What you should now be able to explain or do

Create a fresh environment for a new project and say why you never install into the system Python. Point VS Code and a notebook at the right environment on purpose. Diagnose "module not found" as a kernel-environment mismatch before reinstalling anything. Run a notebook end to end.

Check yourself

Projects need different — sometimes conflicting — library versions. A shared environment lets project B's upgrade silently break project A; isolation makes each project's setup permanent.

The kernel: which environment is the notebook actually running? The install almost certainly went to a different one — align them before touching pip again.

The Python process executing the cells — choosing a kernel chooses which environment (and its packages) the notebook lives in.

A fresh environment, two packages installed into it, and a notebook on its kernel that imports them and draws a plot — every layer aligned, end to end.

Go deeper

Back to Set up your machine: work through the checklist