Set up Python, pip, Jupyter and VS Code for data work

The concept in plain words

Before you can pull a single candle from Binance or run a backtest, you need a workbench. For finance and crypto data work, that workbench is three things working together: Python itself (the language), pip (the tool that installs the libraries you'll rely on — pandas, numpy, requests, matplotlib), and an editor you can actually think in — either Jupyter notebooks for exploring data interactively, or VS Code for writing reusable scripts. You don't need a powerful machine or a cloud account to start. A laptop, a terminal, and twenty minutes of setup gets you a working data-science environment that every other lesson in this course assumes you already have.

The key idea to internalize now: you will isolate every project in its own virtual environment. This single habit prevents the single most common beginner problem — "it worked yesterday, now everything is broken" — because library versions stop colliding across projects.

Think about why this matters specifically for finance and crypto work. A Binance API wrapper you install for this course might pin requests==2.28, while a Dune client you add six months from now wants requests>=2.31. Without isolation, installing the second project's dependencies can silently break the first — and because price data pipelines often run unattended (a cron job pulling candles every hour, for example), a broken import doesn't show up as an error on your screen, it shows up as missing data three days later when you go looking for it. A virtual environment per project means each one freezes its own exact dependency versions, so upgrading or experimenting in one project can never quietly break another.

The other reason this setup lesson exists before any pandas or API content: every other lesson in this course assumes a specific, working toolchain. If your pandas version is two major releases behind, some of the syntax shown later (particularly around resampling and merging in Module 3) may behave differently or raise deprecation warnings. Pinning versions now, and recording them in requirements.txt, means that if something breaks later you have one clear question to ask — "did a library version change?" — instead of guessing across your whole machine.

Worked example

Install Python 3.11+ from python.org (or use pyenv if you manage multiple versions), then from your terminal:

# Create a project folder and a virtual environment inside it
mkdir finance-python && cd finance-python
python3 -m venv .venv

# Activate it — macOS/Linux
source .venv/bin/activate
# Activate it — Windows
.venvScriptsactivate

# Confirm you're using the venv's Python
which python   # should point inside .venv

# Install the core data-work stack
pip install pandas numpy requests jupyterlab matplotlib seaborn python-dotenv

# Freeze what you installed so it's reproducible
pip freeze > requirements.txt

Launch Jupyter to confirm everything works:

jupyter lab

In the notebook that opens, run:

import pandas as pd
import numpy as np
print(pd.__version__, np.__version__)

If both version numbers print without error, your environment is live. For VS Code, install the Python extension, open the finance-python folder, and select .venv as the interpreter (bottom-right status bar, or Cmd/Ctrl+Shift+P → "Python: Select Interpreter"). VS Code will now run and debug scripts using the exact same environment Jupyter uses — no mismatch between "the notebook version" and "the script version" of your code.

One more habit worth building immediately: store secrets (API keys you'll add in Module 2) in a .env file, never hard-coded in a script:

echo "BINANCE_API_KEY=your_key_here" >> .env
echo ".env" >> .gitignore

from dotenv import load_dotenv
import os
load_dotenv()
key = os.getenv("BINANCE_API_KEY")

This keeps credentials out of any code you share or push to GitHub later in the course.

Exercise

Set up your own finance-python project folder following the steps above. Then:

1. Create a virtual environment and activate it.
2. Install pandas, numpy, requests, jupyterlab, matplotlib, and python-dotenv.
3. Write a .gitignore that excludes .venv/ and .env.
4. In a new Jupyter notebook, import pandas and numpy, build a one-line pd.Series([1, 2, 3]), and print it to confirm the kernel is using your venv.
5. Open the same folder in VS Code, point it at .venv, and run a one-line script (print("environment ready")) to confirm script execution also uses the venv.

If step 4 and step 5 both run without import errors, your environment matches what every later lesson in this course expects.

As a final check, verify your requirements.txt actually lists specific versions rather than bare package names (e.g. pandas==2.1.4, not just pandas) — this is what makes the environment reproducible on a second machine, which matters later when you deploy a scheduled job to a server in Module 7 and need the server's environment to match your laptop's exactly.

Recap

• A virtual environment isolates each project's library versions so nothing collides across courses or jobs — and so a scheduled job running unattended doesn't fail silently months later.
• pip install plus pip freeze > requirements.txt makes your setup reproducible on any machine, including the server you'll deploy to in Module 7.
• Jupyter is for exploring data interactively; VS Code (pointed at the same .venv) is for writing the scripts and modules you'll reuse — and .env keeps API keys out of your code from day one.