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

Should we AutoDoc the Documentation? #27

Closed
gully opened this issue Jan 18, 2016 · 3 comments
Closed

Should we AutoDoc the Documentation? #27

gully opened this issue Jan 18, 2016 · 3 comments
Labels

Comments

@gully
Copy link
Collaborator

gully commented Jan 18, 2016

The existing documentation and cookbook contains nice written descriptions of how the code works.

I have added some practical examples and figures to the documentation in Pull Request #23. However, every time I perform make html, I find that the new html content differs from the "live" html content in ways I did not expect. Specifically, the pages Grid Tools, Spectrum, Spectral Emulator, and Model contain API info from Autodoc.

As it stands, the new Autodoc API content looks cluttered, making it difficult to follow the descriptive text. I found a way to turn off the API content (by removing sphinx.ext.autodoc from the conf.py file). So I will do this, and the submit the new documentation content from PR #23.

But then the question is, should we have autodoc? I'm fairly agnostic on this point. But in principle, one could arrange it so that the descriptive content is at the top, and then the API class and method info is at the bottom. Or something sane like that.

I'll leave this here in case anyone has feelings either way.

gully added a commit to gully/Starfish that referenced this issue Jan 18, 2016
gully added a commit to gully/Starfish that referenced this issue Jan 18, 2016
gully added a commit to gully/Starfish that referenced this issue Jan 19, 2016
* upstream/gh-pages:
  Updated docs for version 1.0.  See note in Issue Starfish-develop#27.
@iancze
Copy link
Collaborator

iancze commented Jan 19, 2016

Thank you very much for the nice examples you contributed! You are right that the original formatting of the autodoc'd API with the examples was somewhat haphazard, and the current formatting reads much more smoothly.

I do think we should use autodoc, because at least more often than not I end up browsing the API docs for a project. As frequently seems to be the case, can we borrow the format set by astropy? If I understand their docs, this would require putting the API references on their own pages.

On a related note, I noticed that on the gh-pages branch we have a 1.0/ folder for the documentation and a symbolic link from the current address. I will fix this to be consistent with the version throughout the rest of the project. Which brings me to another issue... I think it's time to create a roadmap for version development :)

@iancze iancze added the doc label Jan 19, 2016
@jason-neal
Copy link
Collaborator

Having the GridInterfaces autodoc'd would be very helpful. Or a mention that the grid interfaces automatically normalize and convert to air wavelengths in some cases would have been helpful somewhere.

I just spent a bunch of time troubleshooting why the grid_tools spectra were different (scaled and shifted) to the raw phoenix ones I manually loaded. They were automatically changed.

@gully
Copy link
Collaborator Author

gully commented May 19, 2017

Hi @jason-neal, I have been experimenting with some changes to Starfish's flux normalization assumptions. Depending on one's goals, the default behavior may not be adequate. Happy to chat about this. See Issue #38 for more info.

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

No branches or pull requests

4 participants