yfinance documentation

[DanielBBar-On]

Hello all,
Is there documentation for yfinance?
Specifically somewhere where I can see the different fields returned by the API calls and the definition of each one?

Thanks.

[ValueRaider]

Not high-quality like the bigger modules. The important methods have docstrings in the source code. Community working on Wiki page

[ValueRaider]

I've recently experimented with sphinx package + github pages to auto-generate documentation. It generates and displays but I haven't figured out adding custom pages e.g. example use. Links for inspiration:

• webpage with one doctstring (I'm lazy): https://valueraider.github.io/yfinance-cacheyfinance_cache.html#yfinance_cache.yfc_ticker.Ticker.history
• script: https://github.com/ValueRaider/yfinance-cache/blob/docs-html/make-docs.sh

@ericpien

[ValueRaider]

Content is good.

Merge strategy has to be targeting the existing documentation branch as I cannot change Github Page settings. It has a docs folder. But first I need to solve it being 3 years old.

[ericpien]

Great. I made the change to build and deploy from the documentation branch's docs folder. i.e. my fork's /documentation/docs by adding publish_branch: documentation on line 34 of deploy_doc.yml and destination_dir: docs on line 36 of deploy_doc.yml.

Once it's all signed off, I'm thinking of creating a PR to dev specifying the GitHub Action to take place upon push to dev branch on line 6 of deploy_doc.yml so we can observe it get built and published once merged. If you have another branch for me to test on, I can do that instead. Then, submit a patch PR so documentation update takes place only upon push to main branch going forward.

[ValueRaider]

documentation now rebased so you can start a PR.

I need to think about what on -> push -> branches should be long-term. main might make more sense so webpages always match main (which always match last release). Can it be documentation for now?

[ericpien]

I can't push to documentation and also publish in the same branch's directory docs as this is not allowed to keep the repo's other files safe. What I could do is push to another branch (i.e. dev or other test branch of preference), and have the workflow set up to build and publish the respective files to documentation/docs directory, from which the site will deploy. (i.e. in my fork, I have it build on push to docs branch, publish to- and deploy from documentation branch's /docs directory for testing purpose.) Given this, do you want me to target dev for the PR?

Eventually, I agree push to main makes the most sense to keep the documentation on the most recent / stable release.

[ValueRaider]

I'm open-minded on this but here is my suggestion:

• target dev-documented first, branched from dev
• over next days/weeks: add docstrings, tweak rst files
• once unrelated changes in dev are pushed into a release, merge dev-documented into dev (or main)