-
Notifications
You must be signed in to change notification settings - Fork 66
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
Document generation system? #4
Comments
|
Here is the Julia style: https://github.com/JuliaLang/julia/tree/master/doc
|
@ovainola did you test the @doc? For me it's looks like that in the future the documentation would be clear:http://julia.readthedocs.org/en/latest/manual/documentation/#other-notes |
@TeroFrondelius I tested the @doc macro. There's a bit more boiler to write if you compare with the notation in the link. Though it doesn't hurt if we do documentation with @doc atm, since we only have to delete couple of words to match it with the new notation. |
Here is our documentation hosting / building system: https://readthedocs.org/ |
And here is the official package for https://readthedocs.org//: https://github.com/JuliaLang/JuliaDoc |
Latest documentation page generated in readTheDocs: http://juliafem.readthedocs.org/en/latest/ |
Ok we're almost done with this issue. We also need something to convert notebooks to rst files in order to progress. After little googling I found a workaround that might work readthedocs/readthedocs.org#579 [quote] notebooks: a conversation about this can be found here |
@ahojukka5 check this: http://juliafem.readthedocs.org/en/latest/getfem_examples/README/ I would claim it's almost working system already. (Obviously some mistake in configuration, because it's called REAME. ) |
Well it's making reference back to GitHub, not rendering the notebooks to html. At least for functional testing the notebooks should be run and checked that they compile. I was thinking something like this, where notebooks are properly rendered to html: http://www.damian.oquanta.info/posts/zen-themes-updated.html Almost forgot, is it possible to get readthedocs url -> juliafem.org/docs? |
@ahojukka5 see #7
|
@ovainola why we don't see our documentation from https://github.com/JuliaFEM/JuliaFEM/blob/master/src/JuliaFEM.jl in our newly generated http://juliafem.readthedocs.org/en/latest/ |
@TeroFrondelius since readTheDocs atm generates documentation from the /docs forder. This feature still needs some configuration. |
This is an alternative https://github.com/MichaelHatherly/Lexicon.jl. It contains doc test as well as some sort of scoring system. |
Looks cool. Magic in the documentation seems to be in the https://github.com/MichaelHatherly/Lexicon.jl/blob/master/docs/build.jl file, which runs all the tests and generates .md files into docs/api/ folder. |
I made some googling and found packages https://github.com/MichaelHatherly/Lexicon.jl & https://github.com/MichaelHatherly/Docile.jl and they seems to be closely linked: Docile provides the @doc macro and Lexicon build and generates the standalone documentation. These packages have more commits & issues (about 10 open vs 60 closed) compared to JuliaDoc ( 2 open and 6 closed) so I'd say we should give them a try. |
Ok, I tried Lexicon.jl and it's quite easy to use. But there's a catch: It's quite heavily linked to Doctile and in the source file it uses @document macro. This forces all the strings above functions to act as docstrings so it's basically automatic @doc for all the string. Here's an example how docstrings have to be written with Lexicon: https://github.com/QuantEcon/QuantEcon.jl/blob/master/src/lqcontrol.jl. It also comes with doctests which is nice. I forked the repository where I've been testing and here's a output of Lexicon: http://juliafemjl.readthedocs.org/en/latest/ note: docstring are written with numpy style and lexicon create markdown which has different syntax. |
@ovainola will the question mark "?" work in REPL with Lexicon.jl? |
Update: works julia> using JuliaFEM
help?> JuliaFEM.elasticity_solver.calc_local_matrices!
calc_local_matrices! (generic function with 1 method)
julia> using Lexicon
help?> JuliaFEM.elasticity_solver.calc_local_matrices!
calc_local_matrices! (generic function with 1 method)
[method]
JuliaFEM.elasticity_solver.calc_local_matrices!(X, u, R, Kt, N, dNdξ, λ_, μ_, ipoints, iweights)
Calculate local tangent stiffness matrix and residual force vector R = T - F
Details:
source: (17,"/home/olli/.julia/v0.4/JuliaFEM/src/elasticity_solver.jl")
and if you have already @doc in front of docstring, Lexicon won't create any documentation.. |
I'd say we give it a try with Lexicon & markdown syntax. If all in favor, I'll make a change in contributing.md |
Hi all, hope you don't mind my input here. When new packages are registered in
The
Yes, Docile provides the backend collection of docstrings while Lexicon handles the presentation.
Recently the need to use
If you'd like that to work for your users immediately then I'd recommend just adding
Docile will document a package that contains only If you run into any problems feel free to ping me with @MichaelHatherly. |
@MichaelHatherly thanks for your comments. Do you know any good example repository, where Lexicon is used together with readthedocs? @ovainola has been studying more this topic, but I will try to briefly describe the wanted process:
|
Basically, Lexicon just extracts the docstrings from your package and dumps them into markdown files. What you do from there is completely up to you. I'm not sure whether you'll be able to get the readthedocs server to do (3) or (4) since that would require having What I've been doing is just using mkdocs, which readthedocs supports, to do the presentation of the generated markdown files. I know Sims.jl has a In your |
I haven't followed this conversation very closely but here's my contribution for subject. In another project I did automatic API documentation generation using Sphinx and Buildbot. In principle it was doing make sphinx-apidoc && make html in makefile which was automatically executed when buildbot polled source and noticed changes. It was one side communication, i.e. buildbot didn't have to pull anything to repository but api documentation was generated on the fly before building documentation. I think we are planning to do something similar with this project. It seems that using readthedocs differs a bit form this approach? |
The readthedocs docs explain it a lot better than I'd be able to: https://read-the-docs.readthedocs.org/en/latest/builds.html and https://read-the-docs.readthedocs.org/en/latest/webhooks.html are probably the most relevant links for what you're interested in doing. |
Ok I almost got working automatic documentation generation (including notebooks!) at juliafem.kapsi.fi. With @ovainola we found several issues related to simple decision whether to use markdown syntax or restructured text format. rst + ipython nbconvert + sphinx is one possibility. nbconvert markdown support is somehow broken, notebooks are not rendered properly. mkdocs uses markdown syntax. Github supports both markdown and rst. So if we get automatic api generation working with rst then I don't see any problems. Using markdown the biggest problems is how to render notebooks. |
@MichaelHatherly Does Lexicon care what kind of syntax you're using inside docstrings? Atm we're using Markdown syntax but If we'll change to reStructuredText does it have some kind of effect? Of course we'll have to change the file suffix to .rst... |
Lexicon uses the Markdown.jl package for docstring parsing, so you'll need to use markdown syntax. There is support for changing the format of docstrings but until there are packages that can parse other formats you'll need to stick with markdown. As far as I know there's no rst parser in the METADATA yet. |
Ok that seems to be issue. Sphinx is not able to parse markdown.
If we end up to write some very primitive parser by ourself (it's doesn't need to be very advanced if we don't use anything special in our docstrings), how do we use it with Lexicon? |
I believe there is some support for it quite recently: sphinx-doc/sphinx#1747
That would be really cool to have. The most important part of Markdown.jl is that it renders markdown docstrings rather nicely in the REPL.
You'd need to add a import Docile.Interface: Docs, data, parsedocs
import ReST # ?
parsedocs(docs::Docs{:rst}) = ReST.parse(data(docs))
Dict(
:format => :rst,
) where |
@MichaelHatherly Could you point me the relevant part of code where this is done using Markdown? As far as I understood this |
Lexicon hooks into Docile's parsing here. That's the equivalent to the line parsedocs(docs::Docs{:rst}) = ReST.parse(data(docs)) that you'd put into a
All the rendering methods are here. (Note that I've linked to the copy of Markdown.jl found in Lexicon. The package has been moved into Julia |
If we want to use numpy docstyle in our code it sounds a good idea to use numpydoc package with sphinx to get things working. Maybe @pv could give us some ideas how to combine julia docstrings with numpydoc..? |
You can probably reuse at least parser and formatter. You may need to modify a few parts IIRC there are autodoc style assumptions on working on Python importable objects. sphinx.ext.napoleon also has a separate implementation of Numpy style parser, don't know if it's tied to Python autodoc or not. |
I tried the following with numpydoc and sphinx.ext.napoleon (the latter also supports numpy documentation style)
Using numpydoc this rendered like it should be while using sphinx.ext.napoleon it gives So what we need to do to get this working is that by using Lexicon save/update we create function header info Then we add numpydoc to conf.py and if everything goes like in movies we should get our api documentation automatically generated. |
Almost working
|
should work now. Problem was the save function with index.rst, which I had commented out in my local repo. I made a commit where I commented the line. Problem isn't fixed yet, but build should pass now |
Possible interestin package https://github.com/jakebolewski/JuliaParser.jl |
Finally, automatic documentation works! Docstrings are read using Lexicon & generated into html with sphinx. Url to documentation: http://www.juliafem.org/api/JuliaFEM.elasticity_solver.html |
This was our last issue in "getting started". |
We need to decide, how to make the manual. I found one potential option:
https://github.com/JuliaLang/JuliaDoc
If I understood correctly this haven't been fully decided in the Julia:
JuliaLang/julia#3988
If you can find more Julia style approach, please bring it to the discussion.
The text was updated successfully, but these errors were encountered: