Skip to content

Cache HTTP responses for docs with VCR#201

Open
Mr0grog wants to merge 1 commit into
mainfrom
docs-are-too-failure-prone
Open

Cache HTTP responses for docs with VCR#201
Mr0grog wants to merge 1 commit into
mainfrom
docs-are-too-failure-prone

Conversation

@Mr0grog
Copy link
Copy Markdown
Member

@Mr0grog Mr0grog commented May 13, 2026

When a lot of builds happen at once, our docs frequently start to fail because of rate limits with the Wayback Machine. Docs builds are also often slow. Both of these are because we use ipython to execute and show the results of code samples in the tutorial, which means we hit live Wayback Machine APIs. This solves the problem by recording and replaying the API responses using VCR, just like we do for tests.

I couldn’t figure out a way to do this entirely with the ipython_execlines setting, since it doesn’t seem to give you a way to execute cleanup/teardown code, and VCR needs that to write out its results. So I wound up with a kind of weird hybrid solution, where I use ipython_execlines to set a directory path to read/write VCR cassettes in, and then have suppressed (hidden) ipython directives at the start and end of the tutorial to begin and clean up VCR recording and replay. It’s not the prettiest approach, but it works.

Fixes #188.

When a lot of builds happen at once, our docs frequently start to fail because of rate limits with the Wayback Machine. Docs builds are also often slow. Both of these are because we use ipython to execute and show the results of code samples in the tutorial, which means we hit live Wayback Machine APIs. This solves the problem by recording and replaying the API responses using VCR, just like we do for tests.

Fixes #188.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Backlog

Development

Successfully merging this pull request may close these issues.

Mock HTTP responses in docs build or remove ipython

1 participant