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

Add sphinx #32

Closed
wants to merge 4 commits into from
Closed

Add sphinx #32

wants to merge 4 commits into from

Conversation

finnkauski
Copy link

@finnkauski finnkauski commented Nov 17, 2019

Reason for PR

Had some spare time and wanted to help out some project and since I started using keybase recently and am a python person I decided to make a contribution.

What this PR adds

I've set up the documentation generation using sphinx in python. Now you can simply run the make documentation (tested on MacOS but should work on linux) and it will build the HTML documentations using the Read the Docs theme in the main folder under docs

Happy to discuss further if any changes have to be made.

What I did do

  • I've added google and numpy docstring support via sphinx.ext.napoleon to see the format click here
  • I have also added the support for type hinted code to get picked up as well, not sure if that is something you would want but i saw you use mypy and if you use any type hints accepted by python they should show up in the docs
  • The read the docs theme for sphinx is also very customisable check their docs out
  • The documentation generation code has a custom snipped I inserted to parse the toml file for the project and insert the version number into the docs dynamically so you don't need to change that
  • The makefile uses the docsrc folder as a storage for docs and for the temporary folder while building the files and then moves them over to the docs folder
  • Add the docs folders to the gitattributes exceptions as to not pollute the language stats for the repo
  • NOTE: to serve docs set your github pages thing to serve from the master/docs folder in the repo settings.

What I DID NOT do

  • write docstrings for your functions and classes (unfortunately I do not have time atm)
  • touch any of the code except adding some example docstrings and module docs at the top
  • integrate the docs into any automatic testing or commit hooks

@nathanmsmith
Copy link
Contributor

nathanmsmith commented Nov 20, 2019

This is awesome! I had been dabbling with something similar in #30, but this is much more complete. cc @xgess

A couple of notes on the PR for @finnkauski:

  • First off, this is a large PR, so sorry in advance if we're not the most quick to review or reply.
  • What would you think about including the generated types (e.g., chat1, stellar1, ...) in the docs?

A couple of notes for us to keep track of Keybase things to do before merging:

  • We should figure out a deployment scheme. I think GitHub pages, like @finnauski mentioned, is a good idea, although I could also see these docs being hosted somewhere around the Keybase docs (although maybe we'd want a theme that better matches the Keybase brand?). This is sort of related to keybase-bot#7. (cc @malgorithms for any ideas on this)
  • We should add some notes in the readme about how to generate documentation, and potentially a pre-commit or travis hook to generate new docs automatically.
  • We should decide on a docstring format and note it in the readme. I personally like the Google style, but am open to either the Numpy style also. I believe there's also a flake8 extension that enforces a style.

@finnkauski
Copy link
Author

You can add the types I suppose. I left the docs unfilled hoping that you would do it. You can add docs for each and it will include them. The obvious issue is the regeneration of new types and their docs getting deleted. I havent used whatever you used to generate the types and haven't dug around in the actual code yet (what is that by the way?)

@finnkauski
Copy link
Author

Sorry last comment. There is a PEP dictating docstring formats that covers types nicely and I think some type checkers could probably parse that. So you could include the type information withing the docs. 2 birds etc.

@finnkauski finnkauski closed this Feb 5, 2024
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.

2 participants