Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sphinx Guidance? #141

Open
ax3l opened this issue Sep 6, 2023 · 4 comments
Open

Sphinx Guidance? #141

ax3l opened this issue Sep 6, 2023 · 4 comments
Labels
question Further information is requested

Comments

@ax3l
Copy link

ax3l commented Sep 6, 2023

Hi,

Thank you so much for this project!

I was reading up a bit and cannot find yet guidance on this:
Which extensions do people use to read stub-only .pyi files into Sphinx docs, e.g., for quick RTD builds?

Are there a few example pybind11 projects you are aware of that build API docs purely from .pyi files?

My workflow is as follows:

  • update .pyi stubs in CI, where I can run a long time (build pybind11 modules)
  • commit .pyi stubs to the repo
  • build on RTD for Sphinx docs (w/o long runtime that would be sufficient to build the pybind11 modules)
@sizmailov
Copy link
Owner

Hi!

As far as I know, none of the listed tools account for *.pyi files in the package.

m.css inspects binary modules, just like pybind11-stubgen does, so that you can get decent results out of the box.

You can make a "fake" module out of generated stubs by renaming all *.pyi files to *.py for doc generation purposes only. I can add --stub-extension= CLI option to make it easier for this use case.

@sizmailov sizmailov added the question Further information is requested label Sep 6, 2023
@ax3l
Copy link
Author

ax3l commented Sep 7, 2023

Thank you for the guidance, renaming is a great suggestion.

Yes on tooling support; I did some checks with sphinx-autoapi, which seems to pick up .pyi files but still eventually struggles when the main C extension is not found.

@virtuald
Copy link
Contributor

What we do is build the wheels in github actions, publish the wheels as an artifact, and then tell RTD to retrieve the correct wheel and install it -- at which point sphinx can do the things it normally does. It requires setting up a token to access the github API, but works great.

@abhinavnatarajan
Copy link

I second @sizmailov's suggestion of renaming - in my own workflow I use the stub files for doc generation rather than the actual wheel because functions in a *.so file cannot be inspected, which means that some functionality of the sphinx autodoc extension does not work properly when using the actual package. I generate the stubs and rename them to *.py files in the CI workflow only for docs generation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants