If you run pdoc module_a followed by pdoc module_b, there will be no cross-linking between the two modules.change the item order?īy default, documentation items are sorted in order of (first) appearance in the source code. This means that you need to run pdoc module_a module_b to have interlinking between module_a and module_b. Pdoc will link all identifiers that are rendered in the current run. While `Doc` only works within the pdoc.doc module. When linking to identifiers in other modules, the identifier name must be fully qualified.įor example, ` ` will be automatically linked to , In your documentation, you can link to other identifiers by enclosing them in backticks: Matched on the final module name, even if modules are passed as file paths.link to other identifiers? would document the pdoc module itself, but none of its submodules. Invocation documents foo and all submodules of foo, but not foo.bar: pdoc foo !foo.bar Each pattern removes all previously specified (sub)module names that match. Alternatively, you can pass negative regular expression !patterns as part of the If you would like to exclude specific submodules from the documentation, the recommended way is to specify _all_ as
To not document the dunder method specifically, but to add some usage examples in the class documentation.Īs a last resort, you can override pdoc's behavior with a custom module template (seeĮxamples/custom-template/ submodules from being documented? If you want to document a special _dunder_ method, the recommended way to do so is.If you want to hide a public member, consider making it private.If you want to document a private member, consider making it public.In general, we recommend keeping these conventions: and are defined in the current module (i.e.If _all_ is not defined, then pdoc will consider all members public that.No other identifiers will be considered public. If _all_ is defined in the module, then all identifiers in that list will be considered public.The public interface of a module is determined through one of two
#Yml devdocs code
For example, the following code shows how toĭefine a function with a docstring and access the contents of thatĬlass GoldenRetriever ( Dog ): breed_code : ClassVar = "GOLD" """International breed code (same for all instances)""" name : str """Full Name (different for each instance)""". The docstring comes from a special placement of a string In Python, objects like modules, functions and classes haveĪ special attribute named _doc_ which contains that object'sĭocstring. That's it – no need to fiddle with any secrets or set up any gh-pages branches.
Copy pdoc's GitHub Actions workflow into your own repository and adjust it to how you build your docs:.Enable GitHub Actions and GitHub Pages in your project's settings.This keeps your docs updated automatically. Pushes your documentation to GitHub Pages.
The generated documentation however you want! pdoc's job is to "just" produce self-contained HTML files for you.Ī very simple way to host your API documentation is to set up a continuous integration job which In this example we'll deploy pdoc's documentation to GitHub Pages. If you need more advanced customization options, see How can I edit pdoc's HTML template?.
0 kommentar(er)
