The third edition teaches one research-to-production process
This repository follows a 27-chapter book rather than presenting a single Python library. The sequence begins with data and research design, moves through features and model families, then reaches simulation, portfolio construction, costs, risk, deployment, and monitoring. Nine case studies apply that process to ETFs, crypto perpetuals, intraday equities, options, foreign exchange, futures, and wider equity panels. The repeated workflow is more useful than a folder of unrelated finance demos.
The methodological stance is the strongest reason to use it. The README separates exploratory tuning from confirmation, uses walk-forward validation, and discusses multiple-testing controls, transaction costs, uncertainty, and strategy retirement. Those topics stop a learner from treating a high backtest score as sufficient evidence. The repository also includes agent-oriented tasks with stated defenses against lookahead bias and leakage. It still cannot supply judgment about whether a market assumption is credible.
Six libraries turn the book into a working stack
The notebooks use six related Python packages for data, feature engineering, models, diagnostics, backtesting, and live operation. That gives readers shared interfaces across the chapters instead of a new miniature framework in every notebook. The model coverage is wide, including linear baselines, gradient boosting, deep time-series models, latent factors, causal methods, reinforcement learning, and language-model work grounded in financial documents.
Breadth has a price. Our environment ended with 523 packages and 10,031 MB before downloading the datasets a reader may need. Some chapters use separate services or runtimes because their libraries do not coexist on the main interpreter. This is reasonable for a book spanning market databases, deep learning, econometrics, and broker integration. It is a poor dependency base for an application that only needs one backtester or one factor model.
What happened when we ran it
Our sandbox installed commit 701fcc7 in 275 seconds, adding 523 packages and occupying 10,031 MB on disk. The build succeeded in 8 seconds. The checkout already held 1,723 files, about 533,709 lines of source, and 279.2 MB. We ran it in a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets.
The test command did not finish within 900 seconds. At the timeout, pytest had reached 12 percent and was continuing through causal and case-study files. The visible tail showed passing dots and many skipped case-study entries, but there was no final summary. A partial stream is not a passed suite, and the log gives no basis for predicting how long the remaining work would take.
Pip-audit reported 12 known vulnerabilities in the installed environment. The supplied result does not include severity or package names, so the defensible finding stops there. The repository has 6 CI workflow files, a compose file, and a tests directory, but no Dockerfile in the checkout. Those signals show substantial engineering machinery without cancelling our timeout or audit result.
Docker reduces platform friction, not resource use
The installation guide recommends Docker Compose with prebuilt images. The main service opens Jupyter Lab, while other profiles cover Python 3.12-only notebooks, storage databases, and GPU work. Local uv installation is narrower: it needs a C/C++ compiler and Python headers because several locked packages build from source. macOS also needs an OpenMP runtime for LightGBM.
Windows users are directed into WSL2, and native Windows Python is unsupported. Intel Mac users need Docker because the required PyTorch wheel is unavailable for local installation. Apple Silicon can use the local uv path, although a subset of notebooks runs through an emulated Python 3.12 container. NVIDIA acceleration belongs on Linux or WSL2 with the appropriate driver and container setup. A class or team should standardize one supported path before troubleshooting notebooks individually.
Data access and provenance remain part of the lesson
The quick start copies .env.example before launching the main service. Defaults are enough to begin, while specific datasets may later require credentials or downloads. Storage benchmarks also start database containers. A notebook can therefore fail because code, environment, external data, registry state, or a service is missing. The repository's installation verifier is worth running before attributing a chapter error to the research itself.
Open issue 558 reports that NASDAQ-100 minute-bar conversion did not create the expected output directory inside Docker. Issue 593 reports a ModuleNotFoundError for scripts when running an ETF case-study command. Issue 614 is even more specific: an FX model path can reference an earlier population that a clean clone does not have, causing failure before fitting. These reports are citable warnings that a large teaching stack still has clean-machine edges.
August 2026 activity outweighs the unfinished run
GitHub recorded 20,708 stars, 9 combined issues and pull requests, and a last push on August 28, 2026. The latest release, v3.0.0-artifacts, was published on July 24 with precomputed case-study artifacts. Current pull requests discuss notebook provenance, corrected selection logic, holdout boundaries, and executed case-study stages. That is active technical work, and the combined open count is not a bug count.
The repository is best approached as a demanding lab course. Keep it in an isolated environment, audit the 12 reported advisories before trusting any network-facing component, and budget more than our 900-second window for verification. Readers who work through the data lineage, evidence boundary, costs, and risk controls will learn more than they would from a thin prediction notebook. Anyone who only needs a backtest API should choose a narrower project and avoid carrying 10,031 MB of curriculum into production.