hansen_singleton_1983: build-time `pd.read_csv` of a vendored CSV over a raw-GitHub URL flakes on HTTP 429

[mmcky]

Surfaced during a QuantEcon/actions container-validation run (test-containers-lectures.yml building this repo).

What happened

lectures/hansen_singleton_1983.md failed to execute:

nbclient.exceptions.CellExecutionError: ...
HTTPError: HTTP Error 429: Too Many Requests

The failing (hidden) cell fetches the dataset over the network:

DATA_URL = (
    "https://github.com/QuantEcon/lecture-python.myst/raw/refs/heads/main/"
    "lectures/_static/lecture_specific/hansen_singleton_1983/"
    "hansen_singleton_1983_data.csv"
)
_data = pd.read_csv(DATA_URL, index_col=0, parse_dates=True)

Root cause

That CSV is already vendored in this repo at lectures/_static/lecture_specific/hansen_singleton_1983/hansen_singleton_1983_data.csv, yet the notebook reads it back over HTTP from github.com/.../raw/.... Under CI load (the container-test matrix builds several repos from GitHub's shared runner IP ranges) raw-GitHub rate-limits the request with HTTP 429 and the build fails. It's non-deterministic — the same notebook passed on the other container in the same run (network luck).

Suggested fix

Read the local checked-out copy instead of the remote URL — the file is already on disk during the build, which removes the network dependency and the flake entirely:

_data = pd.read_csv(
    "_static/lecture_specific/hansen_singleton_1983/hansen_singleton_1983_data.csv",
    index_col=0, parse_dates=True,
)

(Confirm the relative path against the notebook's execution CWD / whatever local-data convention the repo already uses.)

Note

lectures/hansen_singleton_1982.md has a parallel _static/lecture_specific/hansen_singleton_1982/ dataset and very likely uses the same raw-GitHub fetch — worth fixing both together.

Context: observed during the Anaconda 2026.06 container migration in QuantEcon/actions; this is not a migration/pandas-3.0 issue — purely the remote fetch.

[mmcky]

Transferring this issue to QuantEcon/actions — on reflection this is only relevant to the container-validation workflow, where the test matrix makes multiple calls to GitHub from shared runner IPs while building several repos and hits raw-GitHub rate limits. The right fix is on the CI/container side (e.g. retries or caching), not in the lectures themselves.

We won't be changing the data-fetch approach in the lectures: switching to local _static/ paths would break the Colab integration, since the published notebooks (lecture-python.notebooks) are a flat directory of .ipynb files with no _static/ folder — every Colab user would hit a FileNotFoundError. That's why the lectures read vendored data over raw GitHub URLs (see also QuantEcon/lecture-python.myst#972, closed for the same reason). Longer term, a shared data-lectures repository will give us a cleaner home for these datasets.