ITADN

Allow persisting Quarto's freeze cache across builds (or expose a `pre-render` hook)

#155Opendrbenvincent 创建于 2026-05-05
Difficulty: [2] IntermediateEffort: [2] MediumPriority: ♨︎ CriticalType: ★ Enhancement
D
drbenvincentcommented
## Prework - [x] Read and abide by the Great Docs [code of conduct](https://www.contributor-covenant.org/version/2/1/code_of_conduct/) and [contributing guidelines](https://github.com/posit-dev/great-docs/blob/main/.github/CONTRIBUTING.md). - [x] Search for duplicates among the [existing issues](https://github.com/posit-dev/great-docs/issues) (both open and closed). ## Proposal **Context.** We're at PyMC Labs evaluating great-docs as the docs generator for a new Bayesian-statistics Python package we're about to release. The package's documentation centres on a gallery of ~18 worked examples, each of which runs MCMC sampling - full execution is on the order of 30–45 minutes. We love what great-docs gives us (auto-generated API reference, `llms.txt`, agent-skills file, modern theming) and want to use it, but we are currently blocked by the inability to persist Quarto's notebook execution cache across builds. Filing this in the hope of unblocking adoption. **Problem.** Projects whose docs include computationally expensive notebooks (Bayesian MCMC, deep learning, large simulations) cannot use great-docs in CI without re-executing every notebook on every build. For our package that's ~30–45 minutes per CI run, which is fragile (transient sampler issues fail unrelated PRs) and prohibitively slow for PR review cycles. Locally it's similarly painful — every `great-docs build` is a cold start. Quarto solves this natively with `execute: freeze: auto` (per file or project-level) plus a `_freeze/` directory that stores executed outputs. The workflow is ideally - do the heavy docs build locally. Remote CI does not re-execute qmd notebooks. **Why it doesn't work today with great-docs.** great-docs renders with `great-docs/` as the Quarto project root, so Quarto looks for `great-docs/_freeze/`. great-docs wipes `great-docs/` at the start of every build (`shutil.rmtree(self.project_path)` in `_prepare_build_directory`). There's no `pre-render` hook in `great-docs.yml`, no project-level `freeze: true` knob, and no public API to insert work between great-docs' setup and `quarto render`. As far as we can see, the freeze cache is structurally impossible to persist across builds today. **Proposal.** Any one of these would probably unblock the use case: 1. **Expose a `pre-render` hook.** great-docs already injects `post-render: scripts/post-render.py` into the generated `_quarto.yml`. Adding a configurable `pre-render` entry (Quarto natively supports it) lets users write a small script that copies their persisted `_freeze/` into the build directory before `quarto render` runs. **Smallest change, most flexible.** Looks like a two-line addition to `_update_quarto_config()`. 2. **Add `freeze: auto` (or `freezer`) to `great-docs.yml`.** Translate to project-level `execute: freeze: auto` in the generated `_quarto.yml`, plus an optional `freezer:` pointing at a path *outside* `great-docs/` so the cache survives `_prepare_build_directory()`. More opinionated but easier for users — no scripting required. 3. **Make `_prepare_build_directory()` preserve `_freeze/`.** Instead of `shutil.rmtree(self.project_path)`, recreate everything *except* `_freeze/` (and possibly `_site/`). Least invasive change to your code, but doesn't help users whose persisted cache lives in their source tree (e.g. checked into git as `docs/_freeze/`). Our preference is (1) because it's the most general and supports the standard Python-docs-site pattern of committing `_freeze/` to the source repo. Thanks for the work on great-docs, we'd love to be able to use it without ultra heavy remote CI docs builds.
1 条评论