1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363
|
# Usage
## Autodoc syntax
*mkdocstrings* works by processing special expressions in your Markdown files.
The syntax is as follows:
```md
::: identifier
YAML block
```
> NOTE: **Resources on YAML.**
> YAML can sometimes be a bit tricky, particularly on indentation.
> Here are some resources that other users found useful to better
> understand YAML's peculiarities.
>
> - [YAML idiosyncrasies](https://salt-zh.readthedocs.io/en/latest/topics/troubleshooting/yaml_idiosyncrasies.html)
> - [YAML multiline](https://yaml-multiline.info/)
The `identifier` is a string identifying the object you want to document.
The format of an identifier can vary from one handler to another.
For example, the Python handler expects the full dotted-path to a Python object:
`my_package.my_module.MyClass.my_method`.
The YAML block is optional, and contains some configuration options:
- `handler`: the name of the handler to use to collect and render this object.
By default, it will use the value defined in the [Global options](#global-options)'s
`default_handler` key, or `"python"`.
- `options`: a dictionary of options passed to the handler's methods responsible both
for collecting and rendering the documentation. These options can be defined
globally (in `mkdocs.yml`, see [Global options](#global-options)),
locally (as described here), or both.
!!! example "Example with the Python handler"
=== "docs/my_page.md"
```md
# Documentation for `MyClass`
::: my_package.my_module.MyClass
handler: python
options:
members:
- method_a
- method_b
show_root_heading: false
show_source: false
```
=== "mkdocs.yml"
```yaml
nav:
- "My page": my_page.md
```
=== "src/my_package/my_module.py"
```python
class MyClass:
"""Print print print!"""
def method_a(self):
"""Print A!"""
print("A!")
def method_b(self):
"""Print B!"""
print("B!")
def method_c(self):
"""Print C!"""
print("C!")
```
=== "Result"
<h3 id="documentation-for-myclass" style="margin: 0;">Documentation for <code>MyClass</code></h3>
<div><div><p>Print print print!</p><div><div>
<h4 id="mkdocstrings.my_module.MyClass.method_a">
<code class="highlight language-python">
method_a<span class="p">(</span><span class="bp">self</span><span class="p">)</span> </code>
</h4><div>
<p>Print A!</p></div></div><div><h4 id="mkdocstrings.my_module.MyClass.method_b">
<code class="highlight language-python">
method_b<span class="p">(</span><span class="bp">self</span><span class="p">)</span> </code>
</h4><div><p>Print B!</p></div></div></div></div></div>
It is also possible to integrate a mkdocstrings identifier into a Markdown header:
```md
## ::: my_package.my_module.MyClass
options:
show_source: false
```
The above is equivalent to:
```md
::: my_package.my_module.MyClass
options:
show_source: false
heading_level: 2
```
## Global options
*mkdocstrings* accepts a few top-level configuration options in `mkdocs.yml`:
- `default_handler`: The handler that is used by default when no handler is specified.
- `custom_templates`: The path to a directory containing custom templates.
The path is relative to the MkDocs configuration file.
See [Theming](theming.md).
- `handlers`: The handlers' global configuration.
- `enable_inventory`: Whether to enable inventory file generation.
See [Cross-references to other projects / inventories](#cross-references-to-other-projects-inventories)
- `locale`: The locale used for translations. See [Internationalization](#internationalization-i18n).
- `enabled` **(New in version 0.20)**: Whether to enable the plugin. Defaults to `true`.
Can be used to reduce build times when doing local development.
Especially useful when used with environment variables (see example below).
!!! example
```yaml title="mkdocs.yml"
plugins:
- mkdocstrings:
enabled: !ENV [ENABLE_MKDOCSTRINGS, true]
custom_templates: templates
default_handler: python
locale: en
handlers:
python:
options:
show_source: false
```
The handlers global configuration can then be overridden by local configurations:
```yaml title="docs/some_page.md"
::: my_package.my_module.MyClass
options:
show_source: true
```
Some handlers accept additional global configuration.
Check the documentation for your handler of interest in [Handlers](handlers.md).
## Internationalization (I18N)
Some handlers support multiple languages.
If the handler supports localization, the locale it uses is determined by the following order of precedence:
- `locale` in [global options](#global-options)
- `theme.language`: used by the [MkDocs Material theme](https://squidfunk.github.io/mkdocs-material/setup/changing-the-language/)
- `theme.locale` in [MkDocs configuration](https://www.mkdocs.org/user-guide/configuration/#theme)
## Cross-references
Cross-references are written as Markdown *reference-style* links:
=== "Markdown"
```md
With a custom title:
[`Object 1`][full.path.object1]
With the identifier as title:
[full.path.object2][]
```
=== "HTML Result"
```html
<p>With a custom title:
<a href="https://example.com/page1#full.path.object1"><code>Object 1</code></a><p>
<p>With the identifier as title:
<a href="https://example.com/page2#full.path.object2">full.path.object2</a></p>
```
Any item that was inserted using the [autodoc syntax](#autodoc-syntax)
(e.g. `::: full.path.object1`) is possible to link to by using the same identifier with the
cross-reference syntax (`[example][full.path.object1]`).
But the cross-references are also applicable to the items' children that get pulled in.
### Finding out the anchor
If you're not sure which exact identifier a doc item uses, you can look at its "anchor", which your
Web browser will show in the URL bar when clicking an item's entry in the table of contents.
If the URL is `https://example.com/some/page.html#full.path.object1` then you know that this item
is possible to link to with `[example][full.path.object1]`, regardless of the current page.
### Cross-references to any Markdown heading
TIP: **Changed in version 0.15.**
Linking to any Markdown heading used to be the default, but now opt-in is required.
If you want to link to *any* Markdown heading, not just *mkdocstrings*-inserted items, please
enable the [*autorefs* plugin for *MkDocs*](https://github.com/mkdocstrings/autorefs) by adding
`autorefs` to `plugins`:
```yaml title="mkdocs.yml" hl_lines="3"
plugins:
- search
- autorefs
- mkdocstrings:
[...]
```
Note that you don't need to (`pip`) install anything more; this plugin is guaranteed to be pulled in with *mkdocstrings*.
!!! example
=== "doc1.md"
```md
## Hello, world!
Testing
```
=== "doc2.md"
```md
## Something else
Please see the [Hello, World!][hello-world] section.
```
=== "Result HTML for doc2"
```html
<p>Please see the <a href="doc1.html#hello-world">Hello, World!</a> section.</p>
```
### Cross-references to a sub-heading in a docstring
TIP: **New in version 0.14.**
If you have a Markdown heading *inside* your docstring, you can also link directly to it.
In the example below you see the identifier to be linked is `foo.bar--tips`, because it's the "Tips" heading that's part of the `foo.bar` object, joined with "`--`".
!!! example
=== "foo.py"
```python
def bar():
"""Hello, world!
# Tips
- Stay hydrated.
"""
```
=== "doc1.md"
```md
::: foo.bar
```
=== "doc2.md"
```md
Check out the [tips][foo.bar--tips]
```
=== "HTML result for doc2"
```html
<p>Check out the <a href="doc1.html#foo.bar--tips">tips</a></p>
```
The above tip about [Finding out the anchor](#finding-out-the-anchor) also applies the same way here.
You may also notice that such a heading does not get rendered as a `<h1>` element directly, but rather the level gets shifted to fit the encompassing document structure. If you're curious about the implementation, check out [mkdocstrings.HeadingShiftingTreeprocessor][] and others.
### Cross-references to other projects / inventories
TIP: **New in version 0.16.**
Python developers coming from Sphinx might know about its `intersphinx` extension,
that allows to cross-reference items between several projects.
*mkdocstrings* has a similar feature.
To reference an item from another project, you must first tell *mkdocstrings*
to load the inventory it provides. Each handler will be responsible of loading
inventories specific to its language. For example, the Python handler
can load Sphinx-generated inventories (`objects.inv`).
In the following snippet, we load the inventory provided by `installer`:
```yaml title="mkdocs.yml"
plugins:
- mkdocstrings:
handlers:
python:
inventories:
- https://installer.readthedocs.io/en/stable/objects.inv
```
Now it is possible to cross-reference `installer`'s items. For example:
=== "Markdown"
```md
See [installer.records][] to learn about records.
```
=== "Result (HTML)"
```html
<p>See <a href="https://installer.readthedocs.io/en/stable/api/records/#module-installer.records">installer.records</a>
to learn about records.</p>
```
=== "Result (displayed)"
See [installer.records][] to learn about records.
You can of course select another version of the inventory, for example:
```yaml
plugins:
- mkdocstrings:
handlers:
python:
inventories:
# latest instead of stable
- https://installer.readthedocs.io/en/latest/objects.inv
```
In case the inventory file is not served under the base documentation URL,
you can explicitly specify both URLs:
```yaml
plugins:
- mkdocstrings:
handlers:
python:
inventories:
- url: https://cdn.example.com/version/objects.inv
base_url: https://docs.example.com/version
```
Absolute URLs to cross-referenced items will then be based
on `https://docs.example.com/version/` instead of `https://cdn.example.com/version/`.
If you need authentication to access the inventory file, you can provide the credentials in the URL, either as `username:password`:
```yaml
- url: https://username:password@private.example.com/version/objects.inv
```
...or with token authentication:
```yaml
- url: https://token123@private.example.com/version/objects.inv
```
The credentials can also be specified using environment variables in the form `${ENV_VAR}`:
```yaml
- url: https://${USERNAME}:${PASSWORD}@private.example.com/version/objects.inv
```
Reciprocally, *mkdocstrings* also allows to *generate* an inventory file in the Sphinx format.
It will be enabled by default if the Python handler is used, and generated as `objects.inv` in the final site directory.
Other projects will be able to cross-reference items from your project.
To explicitly enable or disable the generation of the inventory file, use the global
`enable_inventory` option:
```yaml
plugins:
- mkdocstrings:
enable_inventory: false
```
|