fix(docs): make gen_ref_pages actually run under mkdocs-gen-files - #3
Merged
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 norun_name(mkdocs_gen_files/plugin.py:43), so__name__is"<run_path>". The entry point sat behindif __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:
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:That's why the call has to be the last statement in the file, not merely unconditional.
Why
__spec__and not a bare callprovide.foundry.docsre-exportsgenerate_reference_pages(docs/__init__.py:8), so a bare module-level call would write files as an import side effect.runpy.run_pathandpython gen_ref_pages.pyboth leave__spec__asNone; a genuine import sets it. That is exactly the distinction needed.scripts/gen_monorepo_ref_pages.py:174already 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 setpython gen_ref_pages.py— reaches generation instead of raising