I typically put the high-level documentation for a Python package into the docstring of its __init__.py file. This makes sense to me, given that the __init__.py file represents the package's interface with the outside world. (And, really, where else would you put it?)
So, I was really quite surprised when I fired up Sphinx for the first time and saw this content buried near the very end of the package documentation, after the content for all of the submodules.
This seems backward to me. The very first thing the user will see when he visits the page for a package is the documentation of the submodule that just happens to come first alphabetically, and the thing he should see first is right near the bottom.
I wonder if there is a way to fix this, to make the stuff inside of __init__.py come out first, before all of the stuff in the submodules. And if I am just going about this in the wrong way, I want to know that. Thanks!
Updated Answer (thank you, Donal Fellows):
https://www.sphinx-doc.org/en/master/man/sphinx-apidoc.html#cmdoption-sphinx-apidoc-M
Original Answer:
Yes, there is an option to do this, it's just not documented here. Inside my copy of Sphinx-1.3.3/sphinx/apidoc.py I found this:
parser.add_option('-M', '--module-first', action='store_true',
dest='modulefirst',
help='Put module documentation before submodule '
'documentation')
I tried it and it works like a charm.
It is also possible to add this option in the conf.py file.
Search in conf.py for the line where the string containing the sphinx-apidoc command is (located in a try section) and add the "--module-first" option.
The new line will look like this:
cmd_line_template = "sphinx-apidoc --module-first -f -o {outputdir} {moduledir}"
Hadn't used Sphinx in a while, but it does seem like they've done a good job updating it. In the past, I had to manually specify the classes since I didn't like how autodoc generated the methods/functions. Now it does seem like you can order them:
.. autoclass:: YourClass
:members: __init__, __getitem__
http://www.sphinx-doc.org/en/stable/ext/autodoc.html
Related
I write documentation for a project using Sphinx. I have code examples (defined as code-blocks, both literally included and just typed inline). In these code examples there are comments, but when I produce documentation translation, they are not extracted into .po files, and obviously are not translated.
How can I translate comments in code examples?
I found other questions about Sphinx modifications. The answers proposed modifying conf.py (making some hooks), creating roles or extensions. I never did that before and I don't know where to start and what solution would be better. Is there any existing solution for this problem?
UPD. These are examples of code I want to show in my documentation:
git clone https://github.com/ynikitenko/lena
# most of requirements are for development only
pip install -r lena/requirements.txt
(here I'd like to translate the comment). A more difficult (maybe not so needed) example is this:
class End(object):
"""Stop sequence here."""
def run(self, flow):
"""Exhaust all preceding flow and stop iteration
(yield nothing to the following flow).
"""
for val in flow:
pass
return
# otherwise it won't be a generator
yield "unreachable"
These examples are formatted with the directive
.. code-block::
I wrote to the official sphinx-users google group, and this is the answer from Matt from Documatt:
It's impossible. Sphinx will have to understand comments in every language.
If you want to translate comments in code-block (and literal blocks after ::), you must translate them all. Add gettext_additional_targets = ["literal-block"] to your conf.py and re-run POT/PO update.
The code lines remain in the "translations" of code, but now the problem is solved for me.
Is there a way to have comments in a _CoqProject file?
I'd like to compile only part of a library, without completely removing all the other files from the _CoqProject file.
# is treated as a comment-the-rest-of-the-line symbol.
I think it is not documented as of now (see issue #7647). But the source code and some experiments show that it works.
In a Maven project with subprojects, each subproject gets an index.html with some content that comes from its POM's description element.
In one of these subprojects, I need that content to contain additional information, including links. There is a section of the doc that suggests I should not do it by trying to put HTML markup in CDATA in the description element (in fact, that doesn't work anyway; the HTML markup just comes out literal). Instead, it suggests there is some better way to get my own content included in the file.
While this element can be specified as CDATA to enable the use of HTML tags
within the description, it is discouraged to allow plain text representation.
If you need to modify the index page of the generated web site, you are able
to specify your own instead of adjusting this text.
Can anyone describe how to do that? I have tried several methods unsuccessfully (I can supply Markdown files with other names and they generate HTML, but a subproject's index.md has no effect on the generated index.html). I have also read about the custom element in site.xml but it seems to require writing a custom Velocity template for the site; I hope the passage "you are able to specify your own" must mean there is some method more straightforward than that.
Of course I would also appreciate a pointer into the docs if there is already an answer I have simply failed to find. (Just pointing me to docs I've already read isn't in itself helpful, though pointing out the answer I missed would be helpful, if it's there.)
In response to inquiries
Directory structure under src/site:
src/site
src/site/resources
src/site/resources/images
src/site/markdown
src/site/markdown/use
src/site/markdown/install
src/site/markdown/examples
src/site/markdown/build
maven-site-plugin version: 3.4
What I mean by 'adding a link':
The part of the index.html that comes from the POM description element
is the central content of the page (not the navigation bar, not the sidebar menus, but the actual content).
I would like that actual-content portion of the page to be able to have a paragraph or two explaining that this is a generated page for developers, and providing links (HTML <a href=...>) for people who arrived at the page from a web search but are really looking for the user-oriented pages.
I can't put that in the description element (even using CDATA), because HTML elements just come out literal. A comment below gives a link to a page on writing a whole custom Velocity template for the site, but is there honestly no simpler way to accomplish this?
I have the same issue. The only thing the generated index.html gives you of value is the list of modules. You can add your own index.md page to src/site/markdown, putting in whatever content you want. To reproduce the list of modules, include something like this:
###Project Modules
This project has declared the following modules:
| Name | Description |
|-|-|
|[Module1 name](module1/index.html)| Module 1 description|
|-|-|
|[Module2 name](module2/index.html)| Module 2 description|
Of course the text is not lifted from the POM. You also have to manually change this file if you have a new module. Not a perfect solution, but the best I could come up with.
Where I wrote:
I can supply Markdown files with other names and they generate HTML,
but a subproject's index.md has no effect on the generated index.html
it turns out the truth is more complex. In a project with subprojects,
there are two places such an index.md might go: in src/site/markdown/subproject-name of the parent project (where all of the other human-written docs for the whole project happen to be), or in a new src/site/markdown directory created within the subproject. A file with any other non-special name can be added in either place, and end up where you expect it in the target. But not for index.md, in that case only the second location can work, and even then, only after a clean.
I had tried both places without success, but trying the second again with a full clean install site site:stage makes it work. Out of the four combinations (parent/clean, parent/noclean, sub/clean, sub/noclean), that was the one I missed trying before posting the question, so of course that's the one that works. :)
If there had been an answer or comment like "hmm, are you sure an index.md in the subproject doesn't work, it works for me?" it probably would have put me quickly back on track. Sometimes after trying several avenues all without success, all that's needed is to know which of them is the one that's supposed to work (if indeed one of them is) and therefore worth spending more time on.
I am writing a small tool in c++. It is actually more of a framework that is open to customization. It has the following directory structure (simplified example).
src/
main/myexec # linked to libapple.so
apple/
coder/libapple.so
john/libapple.so
.
.
james/libapple.so
Here, the directory "coder" is a generic dummy, with some example code to generate libapple.so. Different users can checkout this tool, create directories of their own, copy the template code from "coder" and customize as they wish. Depending on the configure option (indicating the user), the respective libapple.so needs to be generated.
As I mentioned, this is a simplified example. It is not a matter of generic programming, inheritance etc. In fact, similar to the "apple" folder there are others like "scripts", "docs", "configs" etc each having similar user specific folders. Also, the tool will be maintained at a single repository location to allow me to support & maintain all the code that is not specific to user. As a policy, users are expected to modify and check-in only the contents of their folders.
The problem I am facing is with "configure.ac". I do not want to use "AC_ARG_WITH" option as it would require each new user to edit configure.ac. Also for each user the AC_CONFIG_FILE entries would be exactly the same except for his folder name. I tried using "--enable-user=User" and then AC_SUBST(USERDIR), which also helps in setting "SUBDIRS = #USERDIR#" in Makefile.am. Everything looks good except for the fact that "Makefile.in" is not getting created under the user folder when I specify "AC_CONFIG_FILE = ([apple/${USERDIR}/Makefile])".
Please advice how to overcome this issue. In the worst case I may end up in creating softlinks :(
After one full day of scratching my head, following is the solution that I have come up with.
Create a file "project_makefiles.m4.in" like this
AC_CONFIG_FILES([ apple/USERDIR/Makefile ]
Add the below to configure.ac
m4_include([project_makefiles.m4])
Create a wrapper script like "build.sh" which will create "project_makefiles.m4" from "project_makefiles.m4.in" by replacing "USERDIR". This is done before the automake.
I use Octopress for blogging. Generally it works well except one occassion -- after typing rake generate, I got depressing output which says something like:
psych.rb:203:in `parse': (<unknown>): mapping values are not allowed in this context at line 3 column 6 (Psych::SyntaxError)
I can't remember how many times I've encounterd this situation. Every time I google the key words above, but got nothing help.
What I can do is to exclude all the source files (*.mkd) from _posts, and add them one by one to check which one goes wrong. I keep checking, and finally it turns out that a minor grammer mistake makes octopress angry.
Life should NOT be that hard. So is it possible to debug a octopress source file to show which line of file is incorrect in grammer? The outputs from rake generate don't make sense at all.
The reason could be wrong JAML in the top part of the post (e.g. ':' in the title), see https://github.com/jekyll/jekyll/issues/549 for more info.
I've seen a similar error ("mapping values are not allowed in this context") when I try to convert markdown files, using Pandoc. Perhaps your error message is coming from pandoc somehow?
Don't bother to debug Octopress. Please migrate to Pelican -- a Python-powered static site generator. It is full-featured, easy to use, and no doubt, generating useful debug information.