Before any lesson teaches you a single idea, one thing has to be true: the compiler is on your PATH and it runs. This page is just that check — two commands that prove it, the output that means "you're good," and how to read it when one of them doesn't.
Two commands, run from a terminal anywhere inside the repo. The first proves the compiler exists and answers; the second proves it can take a real program from source all the way to a running result.
Proves the odin binary is found on your PATH and can run. It prints where it lives and which build it is.
The exact string is yours alone — the path, the date, and the hash all depend on your machine and which nightly you pulled. Don't match it character for character. The signal that matters: a line came back at all, naming a path to odin.exe and a version … tag. That means it's installed and on PATH.
Proves the toolchain works end to end: it compiles a tiny program and runs the result. A package is just the directory of .odin files; . is "this directory."
This output is real — that exact line is produced by compiling and running this exact program, pinned by a passing claim (claims/lessons/00-setup-check/solution). If that line prints, the compiler took source → built a binary → ran it, and every later lesson will build the same way.
Single-file variant: if you ever have one loose file rather than a package directory, odin run main.odin -file compiles just that file. Same result — the -file flag just says "treat this one file as the whole program" instead of the directory.
dev-…-nightly:<hash> rather than something like 1.0. Odin ships as dated nightly builds; the date and commit hash are the version. So "yours will differ" isn't a hedge — it's the expected state. As long as a path-to-odin.exe and a version line print, the check passes regardless of the date.
Only one thing really goes wrong at this stage, and it has a recognizable shape. The point isn't to memorize an error string — those are produced by your shell and operating system, not by Odin, so they read differently on every machine. The point is to recognize which of two situations you're in.
You typed odin version and the shell complained that it has never heard of odin — no compiler output at all, because the compiler never ran.
This is a PATH problem, not an Odin problem. The binary may well be on disk — the shell just doesn't know where to look. Two ways to tell them apart: run the compiler by its full path (e.g. point directly at odin.exe in your install folder). If that works, the file is fine and only PATH is unset. If even the full path fails, the binary isn't installed where you think it is. Fix PATH (or the install), open a fresh terminal so it re-reads PATH, and re-run odin version.
odin run . errorsA different situation entirely: odin version printed fine, so the compiler is installed and on PATH — but odin run . reported an error and produced no program output.
Now the toolchain is healthy; the message is the compiler talking, and it's pointing at the code or the directory, not the install. The usual cause at this step is running from the wrong place (no .odin files in the current directory) or a typo in the program. That's no longer a setup problem — it's the compiler doing its job, and reading what it says is exactly the skill the next lessons build.
The one distinction to keep: if odin version won't print, the compiler isn't reachable — that's PATH/install. If odin version prints but odin run . fails, the compiler is fine and is telling you about your code. The whole setup check is just confirming you're past the first case, so that from here on every error you see is the real, useful kind.