Using VS Code for This Course

This is the whole life of a virtual environment (venv) — a private package folder for one project so its libraries never clash with another project's. Pick the block for your operating system; the commands do the same two things.

1. python3 -m venv .venv (Windows: py -m venv .venv) creates the environment in a hidden folder called .venv. You do this once per project — the folder then just sits there.
2. source .venv/bin/activate (Windows: .venv\Scripts\Activate.ps1) turns it on for the current terminal. You repeat this every time you open a new terminal — activation does not stick.
3. After activating, python and pip point into .venv, so anything you install lands there and nowhere else.

What the output means: Your prompt gains a (.venv) prefix, e.g. (.venv) you@machine content-assistant %. That prefix is your proof the environment is active — no prefix means you're back on the system Python.

Try this: Run which python (Windows: where python) before and after activating. Before, it points at a system path; after, it points inside .venv. That is exactly what changed.

With the venv active ((.venv) showing), this installs every library the course uses in one shot, reading the list from a requirements file — so no lesson later fails on a missing module.

1. cd path/to/llm-course/code moves you into the folder that contains requirements.txt. The cd ("change directory") step matters because the next command looks for that file in the current folder.
2. pip install -r requirements.txt tells pip to read the file (-r = "from this requirements list") and download every library named in it into your active venv.

What the output means: A stream of downloads ending in Successfully installed anthropic boto3 …. Each name is one library now available to import in your code.

Try this: If you only need a couple of libraries for one chapter, you can skip the big file and run e.g. pip install anthropic on its own — same command, just one package.

An API key is your private password for the Claude API. You store it in an environment variable — a named value the shell holds in memory — so your code can read it without the key ever being written into a file you might share or commit.

1. export ANTHROPIC_API_KEY="sk-ant-…" (Windows PowerShell: $env:ANTHROPIC_API_KEY="sk-ant-…") puts your key into that named variable for the current terminal session.
2. echo $ANTHROPIC_API_KEY (Windows: echo $env:ANTHROPIC_API_KEY) prints the value back so you can confirm it was set. echo just means "print this to the screen".
3. The Anthropic SDK looks for this exact variable name automatically, so your Python code never has to contain the key itself.

What the output means: The echo line should print your key (starting sk-ant-). If it prints a blank line, the variable isn't set — re-run the export line in this same terminal.

Try this: Open a brand-new terminal and run the echo again — it will be blank, because export only lasts for the terminal you ran it in. That's why the tip below shows how to make it stick.

This is not code to run — it's the rhythm every lab follows, listed in order. Read it as a checklist you repeat for each project until it's muscle memory.

1. Steps 1–2 get you set up: open the project folder (not a loose file) and open the integrated terminal.
2. Step 3 activates the venv — and the crucial confirmation is that your prompt now shows (.venv). If it doesn't, stop and fix that before continuing.
3. Steps 4–6 are the actual work: create the lab's files, run the script with python <file>.py, then run the tests with python -m pytest tests/ -v.
4. Steps 7–8 are optional: set your API key to "go live", and ask the Anthropic extension whenever you're stuck.

Try this: The two lines that trip up beginners are steps 3 and 6. If a command "can't find" a package, you almost always skipped step 3 (activation).

This is a configuration file, not a program — VS Code reads it automatically for this folder. It's written in JSON: a set of "name": value pairs inside curly braces, separated by commas. It saves you re-selecting the interpreter every time.

1. "python.defaultInterpreterPath" points VS Code at your venv's Python. Replace the /ABSOLUTE/PATH/TO/.venv/bin/python placeholder with the real path (run which python while the venv is active to get it).
2. "python.terminal.activateEnvironment": true makes new terminals turn the venv on for you.
3. "python.testing.pytestEnabled" plus "python.testing.pytestArgs": ["."] wire up the Testing panel to find and run your pytest suite in the current folder.
4. "python.analysis.extraPaths" tells the code checker where the installed packages live, which clears the red underline under your import lines.

What the output means: No visible output — VS Code silently uses these settings. You'll notice the effect: the correct interpreter is pre-selected and the red squiggles under imports disappear.

Try this: After saving, run Developer: Reload Window from the Command Palette so VS Code re-reads the file. JSON is picky — a missing comma or a stray trailing comma will make it ignore the whole file.

The green ▷ Run button uses VS Code's selected interpreter, which can differ from the one your terminal activated. This optional file forces the Run/Debug button onto your venv so both agree.

1. "name" is just the label you'll see in the Run menu — call it anything.
2. "program": "${file}" means "run whichever file is currently open". ${file} is a VS Code variable it fills in for you.
3. "python" is the important line: point it at your venv's Python (the same /ABSOLUTE/PATH/TO/.venv/bin/python) so the button never uses a different one.
4. "cwd": "${workspaceFolder}" runs the file from the folder you opened, so relative paths behave like they do in the terminal.

Try this: Reload the window, then click ▷. If a script that worked in the terminal now also works from the button, this file did its job.

A multi-root workspace is a single .code-workspace file that groups several folders. Its own "settings" block beats every folder's .vscode/settings.json — which is why a per-folder interpreter can be silently ignored. The fix is to set Python here instead.

1. "folders" lists the folders in the workspace — the /* ... */ is just a placeholder comment for whatever's already there; leave it as-is.
2. The "settings" block is the override. Putting "python.defaultInterpreterPath" here makes it win over any folder-level file.
3. "python.terminal.activateEnvironment": false is set to false on purpose here — in a workspace you often let the shell hook (section 10) handle activation instead, avoiding a fight between the two.

Try this: Not sure you're even in a workspace? The Explorer title shows "WORKSPACE" and the File menu offers "Save Workspace As". If so, edit this file, not the folder's.

This is a small shell function you paste once into ~/.zshrc (the file zsh runs at startup). It makes your venv switch on the moment any terminal enters your project folder, and off when you leave — with nothing to type. macOS/Linux only.

1. my_course_venv() defines the function. The two local lines set proj (your project folder) and venv (your venv) — replace both placeholder paths with your real ones.
2. The if [[ "$PWD" == "$proj"* ]] test asks "is the current folder ($PWD) inside my project?" The trailing * means subfolders count too. If yes and the venv isn't already on, it runs source …/activate.
3. The elif branch handles leaving: if you've stepped out of the project but the course venv is still on, it runs deactivate to turn it off.
4. add-zsh-hook chpwd my_course_venv tells zsh to call the function on every directory change (chpwd), and the bare my_course_venv line runs it once when the shell first opens.

What the output means: Enter the folder → prompt shows (.venv); leave it → the prefix disappears. It behaves the same in VS Code's terminal, Terminal.app, and iTerm, because they all read ~/.zshrc.

Try this: To use it in a terminal you already have open (without restarting), run source ~/.zshrc, then cd into and out of your project and watch the prompt change.

This tiny script is a health check: it proves the Anthropic library is installed in the exact Python that VS Code and your terminal are using. It needs no API key — it only imports and prints, it doesn't call the API.

1. from anthropic import Anthropic and import anthropic load the library. If the venv is wrong or the install failed, this line errors immediately with ModuleNotFoundError — which is itself a useful signal.
2. print("anthropic version:", anthropic.__version__) shows which version got installed.
3. print("python:", sys.executable) prints the full path of the Python actually running the script — this is the line that tells you whether you're in the right venv.
4. Run it with python check_setup.py from your activated venv.

What the output means: A version number, a python: path that should end in .venv/bin/python, and import OK. If the path is a system Python (like /usr/bin), the wrong interpreter is active — revisit sections 4 and 9.

Try this: Deliberately run it without activating the venv. You'll likely get ModuleNotFoundError or a system python: path — a clear picture of what "wrong environment" looks like.