Skip to content

fix(docs): make gen_ref_pages actually run under mkdocs-gen-files - #3

Merged
livingstaccato merged 1 commit into
mainfrom
fix/gen-ref-pages-never-runs
Aug 27, 2026
Merged

fix(docs): make gen_ref_pages actually run under mkdocs-gen-files#3
livingstaccato merged 1 commit into
mainfrom
fix/gen-ref-pages-never-runs

Conversation

@livingstaccato

Copy link
Copy Markdown
Member

The API reference generator has never executed, in any invocation path. Every project that inherits this docs setup has been publishing a reference section containing one hand-written index page.

Under the plugin

mkdocs-gen-files runs a configured script with runpy.run_path(file_name) and no run_name (mkdocs_gen_files/plugin.py:43), so __name__ is "<run_path>". The entry point sat behind if __name__ == "__main__", which therefore never fired — the file defined its functions and returned.

The plugin cannot distinguish a script that generated nothing from one that had nothing to generate, so this failed silently. Downstream it shows up as dangling links out of the hand-written docs/reference/index.md, which looks like a docs-authoring problem and isn't.

Measured on provide-foundation:

pages mkdocs warnings
before 1 91
after 353 9

The 9 remaining are genuine griffe complaints about that project's own docstrings, fixed separately.

Under direct execution

Also broken, differently. The guard sat above the helpers generate_reference_pages() calls:

$ python gen_ref_pages.py
NameError: name '_resolve_src_root' is not defined

That's why the call has to be the last statement in the file, not merely unconditional.

Why __spec__ and not a bare call

provide.foundry.docs re-exports generate_reference_pages (docs/__init__.py:8), so a bare module-level call would write files as an import side effect. runpy.run_path and python gen_ref_pages.py both leave __spec__ as None; a genuine import sets it. That is exactly the distinction needed.

scripts/gen_monorepo_ref_pages.py:174 already calls its entry point unconditionally at module level — this brings the per-project script into line with the variant that works.

Verified

  • import provide.foundry.docs — no generation, __spec__ is set
  • python gen_ref_pages.py — reaches generation instead of raising
  • plugin path — covered by the consuming provide-foundation build
  • ruff check, ruff format, mypy strict all clean

The API reference generator has never executed, in any invocation path.

mkdocs-gen-files runs a configured script with `runpy.run_path(file_name)`
and no run_name (mkdocs_gen_files/plugin.py:43), which leaves __name__ as
"<run_path>". The entry point sat behind `if __name__ == "__main__"`, so
under the plugin the file defined its functions and returned. The plugin
cannot tell a script that generated nothing from one with nothing to
generate, so every consuming project built its one hand-written
docs/reference/index.md and nothing else -- and every link from that page
into the generated tree dangled.

Measured on provide-foundation: 1 reference page and 91 mkdocs warnings
before, 353 pages and 9 warnings after, the 9 being genuine griffe
complaints about that project's own docstrings.

The guard was broken for direct execution too. It sat above the helpers
generate_reference_pages() calls, so `python gen_ref_pages.py` died with

  NameError: name '_resolve_src_root' is not defined

That is why the call now has to be the last statement in the file rather
than merely unconditional.

Gated on `__spec__ is None` rather than made bare: runpy and direct
execution both leave __spec__ unset, while a real import sets it, and
provide.foundry.docs re-exports generate_reference_pages -- writing files
is not a side effect an import may have.

Verified all three paths: import is side-effect free with __spec__ set,
direct execution reaches generation instead of raising, and the plugin
path is covered by the consuming build.
@livingstaccato
livingstaccato merged commit d91a130 into main Aug 27, 2026
11 checks passed
@livingstaccato
livingstaccato deleted the fix/gen-ref-pages-never-runs branch August 27, 2026 08:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant