Set handler's name (a71ab12 by Timothée Mazzucotelli).
Update *.html top-level templates to extend the *.html.jinja base templates (a8c540e by Timothée Mazzucotelli). Issue-151
Update *.html base templates to extend their *.html.jinja counterpart, while overriding the logs block to issue a logging message (info) stating that extending *.html templates is deprecated (e6f1b9c by Timothée Mazzucotelli). Issue-151
Add *.html.jinja top-level (overridable) templates, extending their base counterpart (7c14924 by Timothée Mazzucotelli). Issue-151
Add *.html.jinja base templates, which are copies of *.html templates, with an additional logs block, and using the updated get_template filter (eced9a5 by Timothée Mazzucotelli). Issue-151
Update get_template filter to support both *.html and *.html.jinja templates, logging a message (info) when *.html templates are overridden by users (3546fd7 by Timothée Mazzucotelli). Issue-151
Log a warning when base templates are overridden (26e3d66 by Timothée Mazzucotelli). Issue-151
Release Insiders features of the $500/month funding goal (bd30106 by Timothée Mazzucotelli). The features and projects related to mkdocstrings-python are:
Show parameter default values within the "list" section style too (55f08f3 by Antoine Dechaume). PR #92, Co-authored-by: Timothée Mazzucotelli pawamoy@pm.me
The signature of the format_signature filter has changed. If you override templates in your project to customize the output, make sure to update the following templates so that they use the new filter signature:
class.html
expression.html
function.html
signature.html
You can see how to use the filter in this commit's changes: f686f4e4.
We take this as an opportunity to go out of beta and bump the version to 1.0.0. This will allow users to rely on semantic versioning.
Set handler's name (a71ab12 by Timothée Mazzucotelli).
Update *.html top-level templates to extend the *.html.jinja base templates (a8c540e by Timothée Mazzucotelli). Issue-151
Update *.html base templates to extend their *.html.jinja counterpart, while overriding the logs block to issue a logging message (info) stating that extending *.html templates is deprecated (e6f1b9c by Timothée Mazzucotelli). Issue-151
Add *.html.jinja top-level (overridable) templates, extending their base counterpart (7c14924 by Timothée Mazzucotelli). Issue-151
Add *.html.jinja base templates, which are copies of *.html templates, with an additional logs block, and using the updated get_template filter (eced9a5 by Timothée Mazzucotelli). Issue-151
Update get_template filter to support both *.html and *.html.jinja templates, logging a message (info) when *.html templates are overridden by users (3546fd7 by Timothée Mazzucotelli). Issue-151
Log a warning when base templates are overridden (26e3d66 by Timothée Mazzucotelli). Issue-151
Release Insiders features of the $500/month funding goal (bd30106 by Timothée Mazzucotelli). The features and projects related to mkdocstrings-python are:
Show parameter default values within the "list" section style too (55f08f3 by Antoine Dechaume). PR #92, Co-authored-by: Timothée Mazzucotelli pawamoy@pm.me
The signature of the format_signature filter has changed. If you override templates in your project to customize the output, make sure to update the following templates so that they use the new filter signature:
class.html
expression.html
function.html
signature.html
You can see how to use the filter in this commit's changes: f686f4e4.
We take this as an opportunity to go out of beta and bump the version to 1.0.0. This will allow users to rely on semantic versioning.
Return all known anchors (9bbfe14 by Timothée Mazzucotelli).
Update for griffe 0.4.0 (831aabb by Timothée Mazzucotelli).
\ No newline at end of file
diff --git a/code_of_conduct/index.html b/code_of_conduct/index.html
index 3cfdc797..a138af37 100644
--- a/code_of_conduct/index.html
+++ b/code_of_conduct/index.html
@@ -1 +1 @@
- Code of Conduct - mkdocstrings-python
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at dev@pawamoy.fr. All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the reporter of any incident.
Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
Community Impact: A violation through a single incident or series of actions.
Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
Community Impact: A serious violation of community standards, including sustained inappropriate behavior.
Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
Consequence: A permanent ban from any sort of public interaction within the community.
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at dev@pawamoy.fr. All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the reporter of any incident.
Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
Community Impact: A violation through a single incident or series of actions.
Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
Community Impact: A serious violation of community standards, including sustained inappropriate behavior.
Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
Consequence: A permanent ban from any sort of public interaction within the community.
Signatures for entire Python programs. Extract the structure, the frame, the skeleton of your project, to generate API documentation or find breaking changes in your API.
An MkDocs plugin to create a list of contributors on the page. The git-committers plugin will seed the template context with a list of GitHub or GitLab committers and other useful GIT info such as last modified date
Signatures for entire Python programs. Extract the structure, the frame, the skeleton of your project, to generate API documentation or find breaking changes in your API.
An MkDocs plugin to create a list of contributors on the page. The git-committers plugin will seed the template context with a list of GitHub or GitLab committers and other useful GIT info such as last modified date
The Python handler uses Griffe to collect documentation from Python source code. The word "griffe" can sometimes be used instead of "signature" in French. Griffe is able to visit the Abstract Syntax Tree (AST) of the source code to extract useful information. It is also able to execute the code (by importing it) and introspect objects in memory when source code is not available. Finally, it can parse docstrings following different styles.
The Python handler uses Griffe to collect documentation from Python source code. The word "griffe" can sometimes be used instead of "signature" in French. Griffe is able to visit the Abstract Syntax Tree (AST) of the source code to extract useful information. It is also able to execute the code (by importing it) and introspect objects in memory when source code is not available. Finally, it can parse docstrings following different styles.
Data collection from source code: collection of the object-tree and the docstrings is done thanks to Griffe.
Support for type annotations: Griffe collects your type annotations and mkdocstrings uses them to display parameter types or return types. It is even able to automatically add cross-references to other objects from your API, from the standard library or third-party libraries! See how to load inventories to enable it.
Recursive documentation of Python objects: just use the module dotted-path as an identifier, and you get the full module docs. You don't need to inject documentation for each class, function, etc.
Support for documented attributes: attributes (variables) followed by a docstring (triple-quoted string) will be recognized by Griffe in modules, classes and even in __init__ methods.
Multiple docstring-styles support: common support for Google-style, Numpydoc-style, and Sphinx-style docstrings. See Griffe's documentation on docstrings support.
Admonition support in Google docstrings: blocks like Note: or Warning: will be transformed to their admonition equivalent. We do not support nested admonitions in docstrings!
Every object has a TOC entry: we render a heading for each object, meaning MkDocs picks them into the Table of Contents, which is nicely displayed by the Material theme. Thanks to mkdocstrings cross-reference ability, you can reference other objects within your docstrings, with the classic Markdown syntax: [this object][package.module.object] or directly with [package.module.object][]
Source code display:mkdocstrings can add a collapsible div containing the highlighted source code of the Python object.
Data collection from source code: collection of the object-tree and the docstrings is done thanks to Griffe.
Support for type annotations: Griffe collects your type annotations and mkdocstrings uses them to display parameter types or return types. It is even able to automatically add cross-references to other objects from your API, from the standard library or third-party libraries! See how to load inventories to enable it.
Recursive documentation of Python objects: just use the module dotted-path as an identifier, and you get the full module docs. You don't need to inject documentation for each class, function, etc.
Support for documented attributes: attributes (variables) followed by a docstring (triple-quoted string) will be recognized by Griffe in modules, classes and even in __init__ methods.
Multiple docstring-styles support: common support for Google-style, Numpydoc-style, and Sphinx-style docstrings. See Griffe's documentation on docstrings support.
Admonition support in Google docstrings: blocks like Note: or Warning: will be transformed to their admonition equivalent. We do not support nested admonitions in docstrings!
Every object has a TOC entry: we render a heading for each object, meaning MkDocs picks them into the Table of Contents, which is nicely displayed by the Material theme. Thanks to mkdocstrings cross-reference ability, you can reference other objects within your docstrings, with the classic Markdown syntax: [this object][package.module.object] or directly with [package.module.object][]
Source code display:mkdocstrings can add a collapsible div containing the highlighted source code of the Python object.
\ No newline at end of file
diff --git a/insiders/changelog/index.html b/insiders/changelog/index.html
index b2c4bf1b..7ae13c26 100644
--- a/insiders/changelog/index.html
+++ b/insiders/changelog/index.html
@@ -1 +1 @@
- Changelog - mkdocstrings-python
mkdocstrings-python Insiders is a private fork of mkdocstrings-python, hosted as a private GitHub repository. Almost1all new features are developed as part of this fork, which means that they are immediately available to all eligible sponsors, as they are made collaborators of this repository.
Every feature is tied to a funding goal in monthly subscriptions. When a funding goal is hit, the features that are tied to it are merged back into mkdocstrings-python and released for general availability, making them available to all users. Bugfixes are always released in tandem.
Sponsorships make this project sustainable, as they buy the maintainers of this project time – a very scarce resource – which is spent on the development of new features, bug fixing, stability improvement, issue triage and general support. The biggest bottleneck in Open Source is time.3
If you're unsure if you should sponsor this project, check out the list of completed funding goals to learn whether you're already using features that were developed with the help of sponsorships. You're most likely using at least a handful of them, thanks to our awesome sponsors!
The moment you become a sponsor, you'll get immediate access to 9 additional features that you can start using right away, and which are currently exclusively available to sponsors:
Thanks for your interest in sponsoring! In order to become an eligible sponsor with your GitHub account, visit pawamoy's sponsor profile, and complete a sponsorship of $10 a month or more. You can use your individual or organization GitHub account for sponsoring.
Important: If you're sponsoring @pawamoy through a GitHub organization, please send a short email to insiders@pawamoy.fr with the name of your organization and the GitHub account of the individual that should be added as a collaborator.4
If you sponsor publicly, you're automatically added here with a link to your profile and avatar to show your support for mkdocstrings-python. Alternatively, if you wish to keep your sponsorship private, you'll be a silent +1. You can select visibility during checkout and change it afterwards.
The following section lists all funding goals. Each goal contains a list of features prefixed with a checkmark symbol, denoting whether a feature is already available or planned, but not yet implemented. When the funding goal is hit, the features are released for general availability.
This section lists all funding goals that were previously completed, which means that those features were part of Insiders, but are now generally available and can be used by all users.
We're building an open source project and want to allow outside collaborators to use mkdocstrings-python locally without having access to Insiders. Is this still possible?
Yes. Insiders is compatible with mkdocstrings-python. Almost all new features and configuration options are either backward-compatible or implemented behind feature flags. Most Insiders features enhance the overall experience, though while these features add value for the users of your project, they shouldn't be necessary for previewing when making changes to content.
We don't want to pay for sponsorship every month. Are there any other options?
Yes. You can sponsor on a yearly basis by switching your GitHub account to a yearly billing cycle. If for some reason you cannot do that, you could also create a dedicated GitHub account with a yearly billing cycle, which you only use for sponsoring (some sponsors already do that).
If you have any problems or further questions, please reach out to insiders@pawamoy.fr.
Are we allowed to use Insiders under the same terms and conditions as mkdocstrings-python?
Yes. Whether you're an individual or a company, you may use mkdocstrings-python Insiders precisely under the same terms as mkdocstrings-python, which are given by the ISC License. However, we kindly ask you to respect our fair use policy:
Please don't distribute the source code of Insiders. You may freely use it for public, private or commercial projects, privately fork or mirror it, but please don't make the source code public, as it would counteract the sponsorware strategy.
If you cancel your subscription, you're automatically removed as a collaborator and will miss out on all future updates of Insiders. However, you may use the latest version that's available to you as long as you like. Just remember that GitHub deletes private forks.
In general, every new feature is first exclusively released to sponsors, but sometimes upstream dependencies enhance existing features that must be supported by mkdocstrings-python. ↩
Note that $10 a month is the minimum amount to become eligible for Insiders. While GitHub Sponsors also allows to sponsor lower amounts or one-time amounts, those can't be granted access to Insiders due to technical reasons. Such contributions are still very much welcome as they help ensuring the project's sustainability. ↩
Making an Open Source project sustainable is exceptionally hard: maintainers burn out, projects are abandoned. That's not great and very unpredictable. The sponsorware model ensures that if you decide to use mkdocstrings-python, you can be sure that bugs are fixed quickly and new features are added regularly. ↩
It's currently not possible to grant access to each member of an organization, as GitHub only allows for adding users. Thus, after sponsoring, please send an email to insiders@pawamoy.fr, stating which account should become a collaborator of the Insiders repository. We're working on a solution which will make access to organizations much simpler. To ensure that access is not tied to a particular individual GitHub account, create a bot account (i.e. a GitHub account that is not tied to a specific individual), and use this account for the sponsoring. After being added to the list of collaborators, the bot account can create a private fork of the private Insiders GitHub repository, and grant access to all members of the organizations. ↩
If you cancel your sponsorship, GitHub schedules a cancellation request which will become effective at the end of the billing cycle. This means that even though you cancel your sponsorship, you will keep your access to Insiders as long as your cancellation isn't effective. All charges are processed by GitHub through Stripe. As we don't receive any information regarding your payment, and GitHub doesn't offer refunds, sponsorships are non-refundable. ↩
\ No newline at end of file
+ Insiders - mkdocstrings-python
mkdocstrings-python Insiders is a private fork of mkdocstrings-python, hosted as a private GitHub repository. Almost1all new features are developed as part of this fork, which means that they are immediately available to all eligible sponsors, as they are made collaborators of this repository.
Every feature is tied to a funding goal in monthly subscriptions. When a funding goal is hit, the features that are tied to it are merged back into mkdocstrings-python and released for general availability, making them available to all users. Bugfixes are always released in tandem.
Sponsorships make this project sustainable, as they buy the maintainers of this project time – a very scarce resource – which is spent on the development of new features, bug fixing, stability improvement, issue triage and general support. The biggest bottleneck in Open Source is time.3
If you're unsure if you should sponsor this project, check out the list of completed funding goals to learn whether you're already using features that were developed with the help of sponsorships. You're most likely using at least a handful of them, thanks to our awesome sponsors!
The moment you become a sponsor, you'll get immediate access to 9 additional features that you can start using right away, and which are currently exclusively available to sponsors:
Thanks for your interest in sponsoring! In order to become an eligible sponsor with your GitHub account, visit pawamoy's sponsor profile, and complete a sponsorship of $10 a month or more. You can use your individual or organization GitHub account for sponsoring.
Important: If you're sponsoring @pawamoy through a GitHub organization, please send a short email to insiders@pawamoy.fr with the name of your organization and the GitHub account of the individual that should be added as a collaborator.4
If you sponsor publicly, you're automatically added here with a link to your profile and avatar to show your support for mkdocstrings-python. Alternatively, if you wish to keep your sponsorship private, you'll be a silent +1. You can select visibility during checkout and change it afterwards.
The following section lists all funding goals. Each goal contains a list of features prefixed with a checkmark symbol, denoting whether a feature is already available or planned, but not yet implemented. When the funding goal is hit, the features are released for general availability.
This section lists all funding goals that were previously completed, which means that those features were part of Insiders, but are now generally available and can be used by all users.
We're building an open source project and want to allow outside collaborators to use mkdocstrings-python locally without having access to Insiders. Is this still possible?
Yes. Insiders is compatible with mkdocstrings-python. Almost all new features and configuration options are either backward-compatible or implemented behind feature flags. Most Insiders features enhance the overall experience, though while these features add value for the users of your project, they shouldn't be necessary for previewing when making changes to content.
We don't want to pay for sponsorship every month. Are there any other options?
Yes. You can sponsor on a yearly basis by switching your GitHub account to a yearly billing cycle. If for some reason you cannot do that, you could also create a dedicated GitHub account with a yearly billing cycle, which you only use for sponsoring (some sponsors already do that).
If you have any problems or further questions, please reach out to insiders@pawamoy.fr.
Are we allowed to use Insiders under the same terms and conditions as mkdocstrings-python?
Yes. Whether you're an individual or a company, you may use mkdocstrings-python Insiders precisely under the same terms as mkdocstrings-python, which are given by the ISC License. However, we kindly ask you to respect our fair use policy:
Please don't distribute the source code of Insiders. You may freely use it for public, private or commercial projects, privately fork or mirror it, but please don't make the source code public, as it would counteract the sponsorware strategy.
If you cancel your subscription, you're automatically removed as a collaborator and will miss out on all future updates of Insiders. However, you may use the latest version that's available to you as long as you like. Just remember that GitHub deletes private forks.
In general, every new feature is first exclusively released to sponsors, but sometimes upstream dependencies enhance existing features that must be supported by mkdocstrings-python. ↩
Note that $10 a month is the minimum amount to become eligible for Insiders. While GitHub Sponsors also allows to sponsor lower amounts or one-time amounts, those can't be granted access to Insiders due to technical reasons. Such contributions are still very much welcome as they help ensuring the project's sustainability. ↩
Making an Open Source project sustainable is exceptionally hard: maintainers burn out, projects are abandoned. That's not great and very unpredictable. The sponsorware model ensures that if you decide to use mkdocstrings-python, you can be sure that bugs are fixed quickly and new features are added regularly. ↩
It's currently not possible to grant access to each member of an organization, as GitHub only allows for adding users. Thus, after sponsoring, please send an email to insiders@pawamoy.fr, stating which account should become a collaborator of the Insiders repository. We're working on a solution which will make access to organizations much simpler. To ensure that access is not tied to a particular individual GitHub account, create a bot account (i.e. a GitHub account that is not tied to a specific individual), and use this account for the sponsoring. After being added to the list of collaborators, the bot account can create a private fork of the private Insiders GitHub repository, and grant access to all members of the organizations. ↩
If you cancel your sponsorship, GitHub schedules a cancellation request which will become effective at the end of the billing cycle. This means that even though you cancel your sponsorship, you will keep your access to Insiders as long as your cancellation isn't effective. All charges are processed by GitHub through Stripe. As we don't receive any information regarding your payment, and GitHub doesn't offer refunds, sponsorships are non-refundable. ↩
\ No newline at end of file
diff --git a/insiders/installation/index.html b/insiders/installation/index.html
index e84fd84e..87d69b70 100644
--- a/insiders/installation/index.html
+++ b/insiders/installation/index.html
@@ -1,5 +1,5 @@
- Getting started with Insiders - mkdocstrings-python
mkdocstrings-python Insiders is a compatible drop-in replacement for mkdocstrings-python, and can be installed similarly using pip or git. Note that in order to access the Insiders repository, you need to become an eligible sponsor of @pawamoy on GitHub.
PyPI Insiders is a tool that helps you keep up-to-date versions of Insiders projects in the PyPI index of your choice (self-hosted, Google registry, Artifactory, etc.).
mkdocstrings-python Insiders is a compatible drop-in replacement for mkdocstrings-python, and can be installed similarly using pip or git. Note that in order to access the Insiders repository, you need to become an eligible sponsor of @pawamoy on GitHub.
PyPI Insiders is a tool that helps you keep up-to-date versions of Insiders projects in the PyPI index of your choice (self-hosted, Google registry, Artifactory, etc.).
The GH_TOKEN environment variable is a GitHub token. It can be obtained by creating a personal access token for your GitHub account. It will give you access to the Insiders repository, programmatically, from the command line or GitHub Actions workflows:
When upgrading Insiders, you should always check the version of mkdocstrings-python which makes up the first part of the version qualifier. For example, a version like 8.x.x.4.x.x means that Insiders 4.x.x is currently based on 8.x.x.
If the major version increased, it's a good idea to consult the changelog and go through the steps to ensure your configuration is up to date and all necessary changes have been made.
When upgrading Insiders, you should always check the version of mkdocstrings-python which makes up the first part of the version qualifier. For example, a version like 8.x.x.4.x.x means that Insiders 4.x.x is currently based on 8.x.x.
If the major version increased, it's a good idea to consult the changelog and go through the steps to ensure your configuration is up to date and all necessary changes have been made.
\ No newline at end of file
diff --git a/license/index.html b/license/index.html
index fdfabb84..d55a0345 100644
--- a/license/index.html
+++ b/license/index.html
@@ -1,4 +1,4 @@
- License - mkdocstrings-python
ISC License
Copyright (c) 2021, Timothée Mazzucotelli
@@ -13,4 +13,4 @@
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/reference/SUMMARY/index.html b/reference/SUMMARY/index.html
index c6aaba73..81837519 100644
--- a/reference/SUMMARY/index.html
+++ b/reference/SUMMARY/index.html
@@ -1 +1 @@
- SUMMARY - mkdocstrings-python
Pre-load modules that are not specified directly in autodoc instructions (::: identifier). It is useful when you want to render documentation for a particular member of an object, and this member is imported from another package than its parent.
For an imported member to be rendered, you need to add it to the __all__ attribute of the importing module.
The modules must be listed as an array of strings. Default: None.
A boolean, or an explicit list of inherited members to render. If true, select all inherited members, which can then be filtered with members. If false or empty list, do not select any inherited member. Default: False.
A boolean, or an explicit list of members to render. If true, select all members without further filtering. If false or empty list, do not render members. If none, select all members and apply further filtering with filters and docstrings. Default: None.
The members ordering to use. Options: alphabetical - order by the members names, source - order members as they appear in the source file. Default: "alphabetical".
A list of filters applied to filter objects based on their name. A filter starting with ! will exclude matching objects instead of including them. The members option takes precedence over filters (filters will still be applied recursively to lower members in the hierarchy). Default: ["!^_[^_]"].
Pre-load modules that are not specified directly in autodoc instructions (::: identifier). It is useful when you want to render documentation for a particular member of an object, and this member is imported from another package than its parent.
For an imported member to be rendered, you need to add it to the __all__ attribute of the importing module.
The modules must be listed as an array of strings. Default: None.
A boolean, or an explicit list of inherited members to render. If true, select all inherited members, which can then be filtered with members. If false or empty list, do not select any inherited member. Default: False.
A boolean, or an explicit list of members to render. If true, select all members without further filtering. If false or empty list, do not render members. If none, select all members and apply further filtering with filters and docstrings. Default: None.
The members ordering to use. Options: alphabetical - order by the members names, source - order members as they appear in the source file. Default: "alphabetical".
A list of filters applied to filter objects based on their name. A filter starting with ! will exclude matching objects instead of including them. The members option takes precedence over filters (filters will still be applied recursively to lower members in the hierarchy). Default: ["!^_[^_]"].
Filters to apply, based on members' names. Each element is a tuple: a pattern, and a boolean indicating whether to reject the object if the pattern matches.
An optional, explicit list of members to keep. When given and empty, return an empty list. When given and not empty, ignore filters and docstrings presence/absence.
Filters to apply, based on members' names. Each element is a tuple: a pattern, and a boolean indicating whether to reject the object if the pattern matches.
An optional, explicit list of members to keep. When given and empty, return an empty list. When given and not empty, ignore filters and docstrings presence/absence.
\ No newline at end of file
diff --git a/search/search_index.json b/search/search_index.json
index 0a2c4c4a..197c87f5 100644
--- a/search/search_index.json
+++ b/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Overview","text":"mkdocstrings-python
A Python handler for mkdocstrings.
The Python handler uses Griffe to collect documentation from Python source code. The word \"griffe\" can sometimes be used instead of \"signature\" in French. Griffe is able to visit the Abstract Syntax Tree (AST) of the source code to extract useful information. It is also able to execute the code (by importing it) and introspect objects in memory when source code is not available. Finally, it can parse docstrings following different styles.
Data collection from source code: collection of the object-tree and the docstrings is done thanks to Griffe.
Support for type annotations: Griffe collects your type annotations and mkdocstrings uses them to display parameter types or return types. It is even able to automatically add cross-references to other objects from your API, from the standard library or third-party libraries! See how to load inventories to enable it.
Recursive documentation of Python objects: just use the module dotted-path as an identifier, and you get the full module docs. You don't need to inject documentation for each class, function, etc.
Support for documented attributes: attributes (variables) followed by a docstring (triple-quoted string) will be recognized by Griffe in modules, classes and even in __init__ methods.
Multiple docstring-styles support: common support for Google-style, Numpydoc-style, and Sphinx-style docstrings. See Griffe's documentation on docstrings support.
Admonition support in Google docstrings: blocks like Note: or Warning: will be transformed to their admonition equivalent. We do not support nested admonitions in docstrings!
Every object has a TOC entry: we render a heading for each object, meaning MkDocs picks them into the Table of Contents, which is nicely displayed by the Material theme. Thanks to mkdocstrings cross-reference ability, you can reference other objects within your docstrings, with the classic Markdown syntax: [this object][package.module.object] or directly with [package.module.object][]
Source code display: mkdocstrings can add a collapsible div containing the highlighted source code of the Python object.
Only filter out imported objects instead of non-public ones after applying filters (e2f4b35 by Timoth\u00e9e Mazzucotelli). Issue-mkdocstrings/griffe-294
Update code for Griffe 0.46 to avoid deprecation warnings (321b407 by Timoth\u00e9e Mazzucotelli).
Change load_external_modules default value to None to support new default mode in Griffe (ae5896c by Timoth\u00e9e Mazzucotelli).
Set handler's name (a71ab12 by Timoth\u00e9e Mazzucotelli).
Update *.html top-level templates to extend the *.html.jinja base templates (a8c540e by Timoth\u00e9e Mazzucotelli). Issue-151
Update *.html base templates to extend their *.html.jinja counterpart, while overriding the logs block to issue a logging message (info) stating that extending *.html templates is deprecated (e6f1b9c by Timoth\u00e9e Mazzucotelli). Issue-151
Add *.html.jinja top-level (overridable) templates, extending their base counterpart (7c14924 by Timoth\u00e9e Mazzucotelli). Issue-151
Add *.html.jinja base templates, which are copies of *.html templates, with an additional logs block, and using the updated get_template filter (eced9a5 by Timoth\u00e9e Mazzucotelli). Issue-151
Update get_template filter to support both *.html and *.html.jinja templates, logging a message (info) when *.html templates are overridden by users (3546fd7 by Timoth\u00e9e Mazzucotelli). Issue-151
Log a warning when base templates are overridden (26e3d66 by Timoth\u00e9e Mazzucotelli). Issue-151
Release Insiders features of the $500/month funding goal (bd30106 by Timoth\u00e9e Mazzucotelli). The features and projects related to mkdocstrings-python are:
Cross-references for type annotations in signatures
Symbol types in headings and table of contents
griffe-inherited-docstrings, a Griffe extension for inheriting docstrings
griffe2md, a tool to output API docs to Markdown using Griffe
See the complete list of features and projects here: https://pawamoy.github.io/insiders/#500-plasmavac-user-guide.
Show parameter default values within the \"list\" section style too (55f08f3 by Antoine Dechaume). PR #92, Co-authored-by: Timoth\u00e9e Mazzucotelli pawamoy@pm.me
The signature of the format_signature filter has changed. If you override templates in your project to customize the output, make sure to update the following templates so that they use the new filter signature:
class.html
expression.html
function.html
signature.html
You can see how to use the filter in this commit's changes: f686f4e4.
We take this as an opportunity to go out of beta and bump the version to 1.0.0. This will allow users to rely on semantic versioning.
Return all known anchors (9bbfe14 by Timoth\u00e9e Mazzucotelli).
Update for griffe 0.4.0 (831aabb by Timoth\u00e9e Mazzucotelli).
"},{"location":"code_of_conduct/","title":"Contributor Covenant Code of Conduct","text":""},{"location":"code_of_conduct/#our-pledge","title":"Our Pledge","text":"
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at dev@pawamoy.fr. All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the reporter of any incident.
Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
Community Impact: A violation through a single incident or series of actions.
Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
Community Impact: A serious violation of community standards, including sustained inappropriate behavior.
Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
Consequence: A permanent ban from any sort of public interaction within the community.
This Code of Conduct is adapted from the Contributor Covenant, version 2.1, available at https://www.contributor-covenant.org/version/2/1/code_of_conduct.html.
Community Impact Guidelines were inspired by Mozilla's code of conduct enforcement ladder.
For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.
This project uses duty to run tasks. A Makefile is also provided. The Makefile will try to run certain tasks on multiple Python versions. If for some reason you don't want to run the task on multiple Python versions, you run the task directly with make run duty TASK.
The Makefile detects if a virtual environment is activated, so make will work the same with the virtualenv activated or not.
If you work in VSCode, we provide an action to configure VSCode for the project.
Commit messages must follow our convention based on the Angular style or the Karma convention:
<type>[(scope)]: Subject\n\n[Body]\n
Subject and body must be valid Markdown. Subject must have proper casing (uppercase for first letter if it makes sense), but no dot at the end, and no punctuation in general.
Scope and body are optional. Type can be:
build: About packaging, building wheels, etc.
chore: About packaging or repo/files management.
ci: About Continuous Integration.
deps: Dependencies update.
docs: About documentation.
feat: New feature.
fix: Bug fix.
perf: About performance.
refactor: Changes that are not features or bug fixes.
style: A change in code style/format.
tests: About tests.
If you write a body, please add trailers at the end (for example issues and PR references, or co-authors), without relying on GitHub's flavored Markdown:
Body.\n\nIssue #10: https://github.com/namespace/project/issues/10\nRelated to PR namespace/other-project#15: https://github.com/namespace/other-project/pull/15\n
These \"trailers\" must appear at the end of the body, without any blank lines between them. The trailer title can contain any character except colons :. We expect a full URI for each trailer, not just GitHub autolinks (for example, full GitHub URLs for commits and issues, not the hash or the #issue-number).
We do not enforce a line length on commit messages summary and body, but please avoid very long summaries, and very long lines in the body, unless they are part of code blocks that must not be wrapped.
These projects were used to build mkdocstrings-python. Thank you!
Python | uv | copier-uv
"},{"location":"credits/#exec-1--runtime-dependencies","title":"Runtime dependencies","text":"Project Summary Version (accepted) Version (last resolved) License click Composable command line interface toolkit >=7.08.1.7 BSD-3-Clause colorama Cross-platform colored terminal text. >=0.40.4.6 BSD License ghp-import Copy your docs directly to the gh-pages branch. >=1.02.1.0 Apache Software License griffe Signatures for entire Python programs. Extract the structure, the frame, the skeleton of your project, to generate API documentation or find breaking changes in your API. >=0.470.47.0.1.2.0 ISC importlib_metadata Read metadata from Python packages >=4.6, >=4.47.1.0 Apache Software License Jinja2 A very fast and expressive template engine. >=2.11.1, >=2.103.1.4 BSD License Markdown Python implementation of John Gruber's Markdown. >=3.3.6, >=3.33.6 BSD License MarkupSafe Safely add untrusted strings to HTML/XML markup. >=2.0.1, >=1.12.1.5 BSD-3-Clause mergedeep A deep merge function for \ud83d\udc0d. >=1.3.41.3.4 MIT License mkdocs Project documentation with Markdown. >=1.6, >=1.41.6.0 BSD-2-Clause mkdocs-autorefs Automatically link across pages in MkDocs. >=0.3.11.0.1 ISC mkdocs-get-deps MkDocs extension that lists all dependencies according to a mkdocs.yml file >=0.2.00.2.0 MIT mkdocstrings Automatic documentation from sources, for MkDocs. >=0.250.25.1 ISC packaging Core utilities for Python packages >=24.0, >=20.524.1 Apache Software License + BSD License pathspec Utility library for gitignore style pattern matching of file paths. >=0.11.10.12.1 Mozilla Public License 2.0 (MPL 2.0) platformdirs A small Python package for determining appropriate platform-specific dirs, e.g. a user data dir. >=2.2.0, >=24.2.2 MIT pymdown-extensions Extension pack for Python Markdown. >=9, >=6.310.8.1 MIT python-dateutil Extensions to the standard Python datetime module >=2.8.12.9.0.post0 BSD License + Apache Software License PyYAML YAML parser and emitter for Python >=5.16.0.1 MIT pyyaml_env_tag A custom YAML tag for referencing environment variables in YAML files. >=0.10.1 MIT License six Python 2 and 3 compatibility utilities >=1.51.16.0 MIT typing_extensions Backported and Experimental Type Hints for Python 3.8+ >=4.1, >=4.0.14.12.2 Python Software Foundation License watchdog Filesystem events monitoring >=2.04.0.1 Apache-2.0 zipp Backport of pathlib-compatible object wrapper for zip files >=0.53.19.2 MIT License"},{"location":"credits/#exec-1--development-dependencies","title":"Development dependencies","text":"Project Summary Version (accepted) Version (last resolved) License ansimarkup Produce colored terminal text with an xml-like markup ~=1.41.5.0 Revised BSD License appdirs A small Python module for determining appropriate platform-specific dirs, e.g. a \"user data dir\". >=1.41.4.4 MIT Babel Internationalization utilities ~=2.102.15.0 BSD-3-Clause backports.tarfile Backport of CPython tarfile module 1.2.0 MIT License black The uncompromising code formatter. >=24.424.4.2 MIT build A simple, correct Python build frontend >=1.21.2.1 MIT License certifi Python package for providing Mozilla's CA Bundle. >=2017.4.172024.6.2 MPL-2.0 cffi Foreign Function Interface for Python calling C code. >=1.121.16.0 MIT charset-normalizer The Real First Universal Charset Detector. Open, modern and actively maintained alternative to Chardet. >=2, <43.3.2 MIT click Composable command line interface toolkit >=7.08.1.7 BSD-3-Clause colorama Cross-platform colored terminal text. >=0.40.4.6 BSD License coverage Code coverage measurement for Python >=5.2.17.5.3 Apache-2.0 cryptography cryptography is a package which provides cryptographic recipes and primitives to Python developers. >=2.042.0.8 Apache-2.0 OR BSD-3-Clause csscompressor A python port of YUI CSS Compressor >=0.9.50.9.5 BSD docutils Docutils -- Python Documentation Utilities >=0.13.10.21.2 Public Domain + Python Software Foundation License + BSD License + GNU General Public License (GPL) duty A simple task runner. >=1.41.4.0 ISC editables Editable installations >=0.50.5 MIT License execnet execnet: rapid multi-Python deployment >=2.12.1.1 MIT failprint Run a command, print its output only if it fails. >=0.11, !=1.0.01.0.2 ISC ghp-import Copy your docs directly to the gh-pages branch. >=1.02.1.0 Apache Software License git-changelog Automatic Changelog generator using Jinja2 templates. >=2.52.5.2 ISC gitdb Git Object Database >=4.0.1, <54.0.11 BSD License GitPython GitPython is a Python library used to interact with Git repositories 3.1.43 BSD-3-Clause htmlmin2 An HTML Minifier >=0.1.130.1.13 BSD idna Internationalized Domain Names in Applications (IDNA) >=2.5, <43.7 BSD License importlib_metadata Read metadata from Python packages >=4.6, >=4.47.1.0 Apache Software License iniconfig brain-dead simple config-ini parsing 2.0.0 MIT jaraco.classes Utility functions for Python class constructs 3.4.0 MIT License jaraco.context Useful decorators and context managers 5.3.0 MIT License jaraco.functools Functools like those found in stdlib 4.0.1 MIT License jeepney Low-level, pure Python DBus protocol wrapper. >=0.4.20.8.0 MIT License Jinja2 A very fast and expressive template engine. >=2.11.1, >=2.103.1.4 BSD License jsmin JavaScript minifier. >=3.0.13.0.1 MIT License keyring Store and access your passwords safely. >=15.125.2.1 MIT License Markdown Python implementation of John Gruber's Markdown. >=3.3.6, >=3.33.6 BSD License markdown-callouts Markdown extension: a classier syntax for admonitions >=0.40.4.0 MIT markdown-exec Utilities to execute code blocks in Markdown files. >=1.81.9.1 ISC markdown-it-py Python port of markdown-it. Markdown parsing, done right! >=2.2.03.0.0 MIT License MarkupSafe Safely add untrusted strings to HTML/XML markup. >=2.0.1, >=1.12.1.5 BSD-3-Clause mdurl Markdown URL utilities ~=0.10.1.2 MIT License mergedeep A deep merge function for \ud83d\udc0d. >=1.3.41.3.4 MIT License mkdocs Project documentation with Markdown. >=1.6, >=1.41.6.0 BSD-2-Clause mkdocs-autorefs Automatically link across pages in MkDocs. >=0.3.11.0.1 ISC mkdocs-coverage MkDocs plugin to integrate your coverage HTML report into your site. >=1.01.1.0 ISC mkdocs-gen-files MkDocs plugin to programmatically generate documentation pages during the build >=0.50.5.0 MIT mkdocs-get-deps MkDocs extension that lists all dependencies according to a mkdocs.yml file >=0.2.00.2.0 MIT mkdocs-git-committers-plugin-2 An MkDocs plugin to create a list of contributors on the page. The git-committers plugin will seed the template context with a list of GitHub or GitLab committers and other useful GIT info such as last modified date >=2.32.3.0 MIT mkdocs-literate-nav MkDocs plugin to specify the navigation in Markdown instead of YAML >=0.60.6.1 MIT mkdocs-material Documentation that simply works >=9.59.5.27+insiders.4.53.11 MIT mkdocs-material-extensions Extension pack for Python Markdown and MkDocs Material. ~=1.31.3.1 MIT mkdocs-minify-plugin An MkDocs plugin to minify HTML, JS or CSS files prior to being written to disk >=0.80.8.0 MIT mkdocstrings Automatic documentation from sources, for MkDocs. >=0.250.25.1 ISC more-itertools More routines for operating on iterables, beyond itertools 10.3.0 MIT License mypy Optional static typing for Python >=1.101.10.0 MIT mypy-extensions Type system extensions for programs checked with the mypy type checker. >=0.4.31.0.0 MIT License nh3 Python bindings to the ammonia HTML sanitization library. >=0.2.140.2.17 MIT packaging Core utilities for Python packages >=24.0, >=20.524.1 Apache Software License + BSD License paginate Divides large result sets into pages for easier browsing ~=0.50.5.6 MIT pathspec Utility library for gitignore style pattern matching of file paths. >=0.11.10.12.1 Mozilla Public License 2.0 (MPL 2.0) pkginfo Query metadata from sdists / bdists / installed packages. >=1.8.11.11.1 MIT platformdirs A small Python package for determining appropriate platform-specific dirs, e.g. a user data dir. >=2.2.0, >=24.2.2 MIT pluggy plugin and hook calling mechanisms for python >=1.5, <2.01.5.0 MIT ptyprocess Run a subprocess in a pseudo terminal ~=0.60.7.0 ISC License (ISCL) pycparser C parser in Python 2.22 BSD-3-Clause Pygments Pygments is a syntax highlighting package written in Python. >=2.13.0, <3.0.02.18.0 BSD-2-Clause pymdown-extensions Extension pack for Python Markdown. >=9, >=6.310.8.1 MIT pyproject_hooks Wrappers to call pyproject.toml-based build backend hooks. 1.1.0 MIT License pytest pytest: simple powerful testing with Python >=8.28.2.2 MIT pytest-cov Pytest plugin for measuring coverage. >=5.05.0.0 MIT pytest-randomly Pytest plugin to randomly order tests and control random.seed. >=3.153.15.0 MIT pytest-xdist pytest xdist plugin for distributed testing, most importantly across multiple CPUs >=3.63.6.1 MIT License python-dateutil Extensions to the standard Python datetime module >=2.8.12.9.0.post0 BSD License + Apache Software License PyYAML YAML parser and emitter for Python >=5.16.0.1 MIT pyyaml_env_tag A custom YAML tag for referencing environment variables in YAML files. >=0.10.1 MIT License readme_renderer readme_renderer is a library for rendering readme descriptions for Warehouse >=35.043.0 Apache License, Version 2.0 regex Alternative regular expression module, to replace re. >=2022.42024.5.15 Apache Software License requests Python HTTP for Humans. >=2.202.32.3 Apache-2.0 requests-toolbelt A utility belt for advanced users of python-requests >=0.8.0, !=0.9.01.0.0 Apache 2.0 rfc3986 Validating URI References per RFC 3986 >=1.4.02.0.0 Apache 2.0 rich Render rich text, tables, progress bars, syntax highlighting, markdown and more to the terminal >=12.0.013.7.1 MIT ruff An extremely fast Python linter and code formatter, written in Rust. >=0.40.4.9 MIT SecretStorage Python bindings to FreeDesktop.org Secret Service API >=3.23.3.3 BSD 3-Clause License semver Python helper for Semantic Versioning (https://semver.org) >=2.133.0.2 BSD six Python 2 and 3 compatibility utilities >=1.51.16.0 MIT smmap A pure Python implementation of a sliding window memory map manager >=3.0.1, <65.0.1 BSD twine Collection of utilities for publishing packages on PyPI >=5.15.1.0 Apache Software License types-Markdown Typing stubs for Markdown >=3.63.6.0.20240316 Apache-2.0 license types-PyYAML Typing stubs for PyYAML >=6.06.0.12.20240311 Apache-2.0 license typing_extensions Backported and Experimental Type Hints for Python 3.8+ >=4.1, >=4.0.14.12.2 Python Software Foundation License urllib3 HTTP library with thread-safe connection pooling, file post, and more. >=1.26.02.2.2 MIT License watchdog Filesystem events monitoring >=2.04.0.1 Apache-2.0 zipp Backport of pathlib-compatible object wrapper for zip files >=0.53.19.2 MIT License
ISC License\n\nCopyright (c) 2021, Timoth\u00e9e Mazzucotelli\n\nPermission to use, copy, modify, and/or distribute this software for any\npurpose with or without fee is hereby granted, provided that the above\ncopyright notice and this permission notice appear in all copies.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\" AND THE AUTHOR DISCLAIMS ALL WARRANTIES\nWITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF\nMERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR\nANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES\nWHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN\nACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF\nOR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.\n
mkdocstrings-python follows the sponsorware release strategy, which means that new features are first exclusively released to sponsors as part of Insiders. Read on to learn what sponsorships achieve, how to become a sponsor to get access to Insiders, and what's in it for you!
"},{"location":"insiders/#what-is-insiders","title":"What is Insiders?","text":"
mkdocstrings-python Insiders is a private fork of mkdocstrings-python, hosted as a private GitHub repository. Almost1 all new features are developed as part of this fork, which means that they are immediately available to all eligible sponsors, as they are made collaborators of this repository.
Every feature is tied to a funding goal in monthly subscriptions. When a funding goal is hit, the features that are tied to it are merged back into mkdocstrings-python and released for general availability, making them available to all users. Bugfixes are always released in tandem.
Sponsorships make this project sustainable, as they buy the maintainers of this project time \u2013 a very scarce resource \u2013 which is spent on the development of new features, bug fixing, stability improvement, issue triage and general support. The biggest bottleneck in Open Source is time.3
If you're unsure if you should sponsor this project, check out the list of completed funding goals to learn whether you're already using features that were developed with the help of sponsorships. You're most likely using at least a handful of them, thanks to our awesome sponsors!
"},{"location":"insiders/#whats-in-it-for-me","title":"What's in it for me?","text":"
The moment you become a sponsor, you'll get immediate access to 9 additional features that you can start using right away, and which are currently exclusively available to sponsors:
Class inheritance diagrams with Mermaid
Annotations modernization
Parameter headings
Automatic cross-references to parameters
Automatic cross-references for default parameter values in signatures
Automatic rendering of function signature overloads
Auto-summary of object members
griffe-warnings-deprecated \u2014 [Project] Griffe extension for @warnings.deprecated (PEP 702)
griffe-pydantic \u2014 [Project] Griffe extension for Pydantic
These are just the features related to this project. See the complete feature list on the author's main Insiders page.
"},{"location":"insiders/#how-to-become-a-sponsor","title":"How to become a sponsor","text":"
Thanks for your interest in sponsoring! In order to become an eligible sponsor with your GitHub account, visit pawamoy's sponsor profile, and complete a sponsorship of $10 a month or more. You can use your individual or organization GitHub account for sponsoring.
Important: If you're sponsoring @pawamoy through a GitHub organization, please send a short email to insiders@pawamoy.fr with the name of your organization and the GitHub account of the individual that should be added as a collaborator.4
You can cancel your sponsorship anytime.5
\u00a0 Join our awesome sponsors
If you sponsor publicly, you're automatically added here with a link to your profile and avatar to show your support for mkdocstrings-python. Alternatively, if you wish to keep your sponsorship private, you'll be a silent +1. You can select visibility during checkout and change it afterwards.
The following section lists all funding goals. Each goal contains a list of features prefixed with a checkmark symbol, denoting whether a feature is already available or planned, but not yet implemented. When the funding goal is hit, the features are released for general availability.
This section lists all funding goals that were previously completed, which means that those features were part of Insiders, but are now generally available and can be used by all users.
"},{"location":"insiders/#500-plasmavac-user-guide","title":"$ 500 \u2014 PlasmaVac User Guide","text":"
Cross-references for type annotations in signatures
Symbol types in headings and table of contents
griffe-inherited-docstrings \u2014 [Project] Griffe extension for inheriting docstrings
We're building an open source project and want to allow outside collaborators to use mkdocstrings-python locally without having access to Insiders. Is this still possible?
Yes. Insiders is compatible with mkdocstrings-python. Almost all new features and configuration options are either backward-compatible or implemented behind feature flags. Most Insiders features enhance the overall experience, though while these features add value for the users of your project, they shouldn't be necessary for previewing when making changes to content.
We don't want to pay for sponsorship every month. Are there any other options?
Yes. You can sponsor on a yearly basis by switching your GitHub account to a yearly billing cycle. If for some reason you cannot do that, you could also create a dedicated GitHub account with a yearly billing cycle, which you only use for sponsoring (some sponsors already do that).
If you have any problems or further questions, please reach out to insiders@pawamoy.fr.
Are we allowed to use Insiders under the same terms and conditions as mkdocstrings-python?
Yes. Whether you're an individual or a company, you may use mkdocstrings-python Insiders precisely under the same terms as mkdocstrings-python, which are given by the ISC License. However, we kindly ask you to respect our fair use policy:
Please don't distribute the source code of Insiders. You may freely use it for public, private or commercial projects, privately fork or mirror it, but please don't make the source code public, as it would counteract the sponsorware strategy.
If you cancel your subscription, you're automatically removed as a collaborator and will miss out on all future updates of Insiders. However, you may use the latest version that's available to you as long as you like. Just remember that GitHub deletes private forks.
In general, every new feature is first exclusively released to sponsors, but sometimes upstream dependencies enhance existing features that must be supported by mkdocstrings-python.\u00a0\u21a9
Note that $10 a month is the minimum amount to become eligible for Insiders. While GitHub Sponsors also allows to sponsor lower amounts or one-time amounts, those can't be granted access to Insiders due to technical reasons. Such contributions are still very much welcome as they help ensuring the project's sustainability.\u00a0\u21a9
Making an Open Source project sustainable is exceptionally hard: maintainers burn out, projects are abandoned. That's not great and very unpredictable. The sponsorware model ensures that if you decide to use mkdocstrings-python, you can be sure that bugs are fixed quickly and new features are added regularly.\u00a0\u21a9
It's currently not possible to grant access to each member of an organization, as GitHub only allows for adding users. Thus, after sponsoring, please send an email to insiders@pawamoy.fr, stating which account should become a collaborator of the Insiders repository. We're working on a solution which will make access to organizations much simpler. To ensure that access is not tied to a particular individual GitHub account, create a bot account (i.e. a GitHub account that is not tied to a specific individual), and use this account for the sponsoring. After being added to the list of collaborators, the bot account can create a private fork of the private Insiders GitHub repository, and grant access to all members of the organizations.\u00a0\u21a9
If you cancel your sponsorship, GitHub schedules a cancellation request which will become effective at the end of the billing cycle. This means that even though you cancel your sponsorship, you will keep your access to Insiders as long as your cancellation isn't effective. All charges are processed by GitHub through Stripe. As we don't receive any information regarding your payment, and GitHub doesn't offer refunds, sponsorships are non-refundable.\u00a0\u21a9
"},{"location":"insiders/changelog/","title":"Changelog","text":""},{"location":"insiders/changelog/#mkdocstrings-python-insiders","title":"mkdocstrings-python Insiders","text":""},{"location":"insiders/changelog/#1.8.3","title":"1.8.3 June 19, 2024","text":"
Update code for Griffe 0.46+ to avoid deprecation warnings
"},{"location":"insiders/changelog/#1.8.2","title":"1.8.2 May 09, 2024","text":"
Don't render cross-refs for default values when signatures aren't separated
"},{"location":"insiders/changelog/#1.8.1","title":"1.8.1 April 19, 2024","text":"
Render enumeration instance name instead of just \"value\", allowing proper cross-reference
"},{"location":"insiders/changelog/#1.8.0","title":"1.8.0 March 24, 2024","text":"
Annotations modernization
"},{"location":"insiders/changelog/#1.7.0","title":"1.7.0 March 24, 2024","text":"
Class inheritance diagrams with Mermaid
"},{"location":"insiders/changelog/#1.6.0","title":"1.6.0 January 30, 2024","text":"
Render cross-references to parameters documentation in signatures and attribute values.
Add parameter_headings option to render headings for parameters (enabling permalinks and ToC/inventory entries).
Render cross-references for default parameter values in signatures.
"},{"location":"insiders/changelog/#1.5.1","title":"1.5.1 September 12, 2023","text":"
Prevent empty auto-summarized Methods section.
"},{"location":"insiders/changelog/#1.5.0","title":"1.5.0 September 05, 2023","text":"
Render function signature overloads.
"},{"location":"insiders/changelog/#1.4.0","title":"1.4.0 August 27, 2023","text":"
Render cross-references in attribute signatures.
"},{"location":"insiders/changelog/#1.3.0","title":"1.3.0 August 24, 2023","text":"
Add \"method\" symbol type.
"},{"location":"insiders/changelog/#1.2.0","title":"1.2.0 August 20, 2023","text":"
Add member auto-summaries.
"},{"location":"insiders/changelog/#1.1.4","title":"1.1.4 July 17, 2023","text":"
Fix heading level increment for class members.
"},{"location":"insiders/changelog/#1.1.3","title":"1.1.3 July 17, 2023","text":"
Fix heading level (avoid with clause preventing to decrease it).
"},{"location":"insiders/changelog/#1.1.2","title":"1.1.2 July 15, 2023","text":"
Use non-breaking spaces after symbol types.
"},{"location":"insiders/changelog/#1.1.1","title":"1.1.1 June 27, 2023","text":"
Correctly escape expressions in signatures and other rendered types.
"},{"location":"insiders/changelog/#1.1.0","title":"1.1.0 June 4, 2023","text":"
Add Symbol types in headings and table of contents.
"},{"location":"insiders/changelog/#1.0.0","title":"1.0.0 May 10, 2023","text":"
Add cross-references for type annotations in signatures. Make sure to update your local templates as the signature of the format_signature filter has changed. The templates that must be updated: class.html, expression.html, function.html and signature.html.
"},{"location":"insiders/installation/","title":"Getting started with Insiders","text":"
mkdocstrings-python Insiders is a compatible drop-in replacement for mkdocstrings-python, and can be installed similarly using pip or git. Note that in order to access the Insiders repository, you need to become an eligible sponsor of @pawamoy on GitHub.
PyPI Insiders is a tool that helps you keep up-to-date versions of Insiders projects in the PyPI index of your choice (self-hosted, Google registry, Artifactory, etc.).
See how to install it and how to use it.
We kindly ask that you do not upload the distributions to public registries, as it is against our Terms of use.
The GH_TOKEN environment variable is a GitHub token. It can be obtained by creating a personal access token for your GitHub account. It will give you access to the Insiders repository, programmatically, from the command line or GitHub Actions workflows:
Go to https://github.com/settings/tokens
Click on Generate a new token
Enter a name and select the repo scope
Generate the token and store it in a safe place
Note that the personal access token must be kept secret at all times, as it allows the owner to access your private repositories.
When upgrading Insiders, you should always check the version of mkdocstrings-python which makes up the first part of the version qualifier. For example, a version like 8.x.x.4.x.x means that Insiders 4.x.x is currently based on 8.x.x.
If the major version increased, it's a good idea to consult the changelog and go through the steps to ensure your configuration is up to date and all necessary changes have been made.
Whether to load stubs package (package-stubs) when extracting docstrings. Default False.
allow_inspection (bool) \u2013
Whether to allow inspecting modules when visiting them is not possible. Default: True.
show_bases (bool) \u2013
Show the base classes of a class. Default: True.
show_inheritance_diagram (bool) \u2013
Show the inheritance diagram of a class using Mermaid. Default: False.
show_source (bool) \u2013
Show the source code of this object. Default: True.
preload_modules (list[str] | None) \u2013
Pre-load modules that are not specified directly in autodoc instructions (::: identifier). It is useful when you want to render documentation for a particular member of an object, and this member is imported from another package than its parent.
For an imported member to be rendered, you need to add it to the __all__ attribute of the importing module.
The modules must be listed as an array of strings. Default: None.
Headings options:
heading_level (int) \u2013
The initial heading level to use. Default: 2.
parameter_headings (bool) \u2013
Whether to render headings for parameters (therefore showing parameters in the ToC). Default: False.
show_root_heading (bool) \u2013
Show the heading of the object at the root of the documentation tree (i.e. the object referenced by the identifier after :::). Default: False.
show_root_toc_entry (bool) \u2013
If the root heading is not shown, at least add a ToC entry for it. Default: True.
show_root_full_path (bool) \u2013
Show the full Python path for the root object heading. Default: True.
show_root_members_full_path (bool) \u2013
Show the full Python path of the root members. Default: False.
show_object_full_path (bool) \u2013
Show the full Python path of every object. Default: False.
show_category_heading (bool) \u2013
When grouped by categories, show a heading for each category. Default: False.
show_symbol_type_heading (bool) \u2013
Show the symbol type in headings (e.g. mod, class, meth, func and attr). Default: False.
show_symbol_type_toc (bool) \u2013
Show the symbol type in the Table of Contents (e.g. mod, class, methd, func and attr). Default: False.
A boolean, or an explicit list of inherited members to render. If true, select all inherited members, which can then be filtered with members. If false or empty list, do not select any inherited member. Default: False.
members (list[str] | bool | None) \u2013
A boolean, or an explicit list of members to render. If true, select all members without further filtering. If false or empty list, do not render members. If none, select all members and apply further filtering with filters and docstrings. Default: None.
members_order (str) \u2013
The members ordering to use. Options: alphabetical - order by the members names, source - order members as they appear in the source file. Default: \"alphabetical\".
filters (list[str] | None) \u2013
A list of filters applied to filter objects based on their name. A filter starting with ! will exclude matching objects instead of including them. The members option takes precedence over filters (filters will still be applied recursively to lower members in the hierarchy). Default: [\"!^_[^_]\"].
group_by_category (bool) \u2013
Group the object's children by categories: attributes, classes, functions, and modules. Default: True.
show_submodules (bool) \u2013
When rendering a module, show its submodules recursively. Default: False.
summary (bool | dict[str, bool]) \u2013
Whether to render summaries of modules, classes, functions (methods) and attributes.
show_labels (bool) \u2013
Whether to show labels of the members. Default: True.
Docstrings options:
docstring_style (str) \u2013
The docstring style to use: google, numpy, sphinx, or None. Default: \"google\".
docstring_options (dict) \u2013
The options for the docstring parser. See parsers under griffe.docstrings.
docstring_section_style (str) \u2013
The style used to render docstring sections. Options: table, list, spacy. Default: \"table\".
merge_init_into_class (bool) \u2013
Whether to merge the __init__ method into the class' signature and docstring. Default: False.
show_if_no_docstring (bool) \u2013
Show the object heading even if it has no docstring or children with docstrings. Default: False.
show_docstring_attributes (bool) \u2013
Whether to display the \"Attributes\" section in the object's docstring. Default: True.
show_docstring_functions (bool) \u2013
Whether to display the \"Functions\" or \"Methods\" sections in the object's docstring. Default: True.
show_docstring_classes (bool) \u2013
Whether to display the \"Classes\" section in the object's docstring. Default: True.
show_docstring_modules (bool) \u2013
Whether to display the \"Modules\" section in the object's docstring. Default: True.
show_docstring_description (bool) \u2013
Whether to display the textual block (including admonitions) in the object's docstring. Default: True.
show_docstring_examples (bool) \u2013
Whether to display the \"Examples\" section in the object's docstring. Default: True.
show_docstring_other_parameters (bool) \u2013
Whether to display the \"Other Parameters\" section in the object's docstring. Default: True.
show_docstring_parameters (bool) \u2013
Whether to display the \"Parameters\" section in the object's docstring. Default: True.
show_docstring_raises (bool) \u2013
Whether to display the \"Raises\" section in the object's docstring. Default: True.
show_docstring_receives (bool) \u2013
Whether to display the \"Receives\" section in the object's docstring. Default: True.
show_docstring_returns (bool) \u2013
Whether to display the \"Returns\" section in the object's docstring. Default: True.
show_docstring_warns (bool) \u2013
Whether to display the \"Warns\" section in the object's docstring. Default: True.
show_docstring_yields (bool) \u2013
Whether to display the \"Yields\" section in the object's docstring. Default: True.
Signatures/annotations options:
annotations_path (str) \u2013
The verbosity for annotations path: brief (recommended), or source (as written in the source). Default: \"brief\".
line_length (int) \u2013
Maximum line length when formatting code/signatures. Default: 60.
show_signature (bool) \u2013
Show methods and functions signatures. Default: True.
show_signature_annotations (bool) \u2013
Show the type annotations in methods and functions signatures. Default: False.
signature_crossrefs (bool) \u2013
Whether to render cross-references for type annotations in signatures. Default: False.
separate_signature (bool) \u2013
Whether to put the whole signature in a code block below the heading. If Black is installed, the signature is also formatted using it. Default: False.
unwrap_annotated (bool) \u2013
Whether to unwrap Annotated types to show only the type without the annotations. Default: False.
modernize_annotations (bool) \u2013
Whether to modernize annotations, for example Optional[str] into str | None. Default: False.
Filters to apply, based on members' names. Each element is a tuple: a pattern, and a boolean indicating whether to reject the object if the pattern matches.
An optional, explicit list of members to keep. When given and empty, return an empty list. When given and not empty, ignore filters and docstrings presence/absence.
You can install this handler as a mkdocstrings extra:
pyproject.toml
# PEP 621 dependencies declaration\n# adapt to your dependencies manager\n[project]\ndependencies = [\n \"mkdocstrings[python]>=0.18\",\n]\n
You can also explicitly depend on the handler:
pyproject.toml
# PEP 621 dependencies declaration\n# adapt to your dependencies manager\n[project]\ndependencies = [\n \"mkdocstrings-python\",\n]\n
The Python handler is the default mkdocstrings handler. You can change the default handler, or explicitely set the Python handler as default by defining the default_handler configuration option of mkdocstrings in mkdocs.yml:
With the Python handler installed and configured as default handler, you can inject documentation for a module, class, function, or any other Python object with mkdocstrings' autodoc syntax, in your Markdown pages:
::: path.to.object\n
If another handler was defined as default handler, you can explicitely ask for the Python handler to be used when injecting documentation with the handler option:
This option is used to import Sphinx-compatible objects inventories from other documentation sites. For example, you can import the standard library objects inventory like this:
When importing an inventory, you enable automatic cross-references to other documentation sites like the standard library docs or any third-party package docs. Typically, you want to import the inventories of your project's dependencies, at least those that are used in the public API.
See mkdocstrings' documentation on inventories for more details.
Additionally, the Python handler accepts a domains option in the import items, which allows to select the inventory domains to select. By default the Python handler only selects the py domain (for Python objects). You might find useful to also enable the std domain:
This option is used to provide filesystem paths in which to search for Python modules. Non-absolute paths are computed as relative to MkDocs configuration file. Example:
mkdocs.yml
plugins:\n- mkdocstrings:\n handlers:\n python:\n paths: [src] # search packages in the src folder\n
This option allows resolving aliases (imports) to any external module. Modules are considered external when they are not part of the package your are injecting documentation for. Setting this option to True will tell the handler to resolve aliases recursively when they are made public through the __all__ variable. By default, the handler will only resolve aliases when they point at a private sibling of the source package, for example aliases going from ast to _ast. Set load_external_modules to False to prevent even that.
Use with caution
This can load a lot of modules through Griffe, slowing down your build or triggering errors that Griffe does not yet handle. We recommend using the preload_modules option instead, which acts as an include-list rather than as include-all.
These options affect how the documentation is collected from sources and rendered. See the following tables summarizing the options, and get more details for each option in the following pages:
General options: various options that do not fit in the other categories
Headings options: options related to headings and the table of contents (or sidebar, depending on the theme used)
Members options: options related to filtering or ordering members in the generated documentation
Docstrings options: options related to docstrings (parsing and rendering)
Signature options: options related to signatures and type annotations
Whether to load stubs package (package-stubs) when extracting docstrings. Default False.
allow_inspection (bool) \u2013
Whether to allow inspecting modules when visiting them is not possible. Default: True.
show_bases (bool) \u2013
Show the base classes of a class. Default: True.
show_inheritance_diagram (bool) \u2013
Show the inheritance diagram of a class using Mermaid. Default: False.
show_source (bool) \u2013
Show the source code of this object. Default: True.
preload_modules (list[str] | None) \u2013
Pre-load modules that are not specified directly in autodoc instructions (::: identifier). It is useful when you want to render documentation for a particular member of an object, and this member is imported from another package than its parent.
For an imported member to be rendered, you need to add it to the __all__ attribute of the importing module.
The modules must be listed as an array of strings. Default: None.
Headings options:
heading_level (int) \u2013
The initial heading level to use. Default: 2.
parameter_headings (bool) \u2013
Whether to render headings for parameters (therefore showing parameters in the ToC). Default: False.
show_root_heading (bool) \u2013
Show the heading of the object at the root of the documentation tree (i.e. the object referenced by the identifier after :::). Default: False.
show_root_toc_entry (bool) \u2013
If the root heading is not shown, at least add a ToC entry for it. Default: True.
show_root_full_path (bool) \u2013
Show the full Python path for the root object heading. Default: True.
show_root_members_full_path (bool) \u2013
Show the full Python path of the root members. Default: False.
show_object_full_path (bool) \u2013
Show the full Python path of every object. Default: False.
show_category_heading (bool) \u2013
When grouped by categories, show a heading for each category. Default: False.
show_symbol_type_heading (bool) \u2013
Show the symbol type in headings (e.g. mod, class, meth, func and attr). Default: False.
show_symbol_type_toc (bool) \u2013
Show the symbol type in the Table of Contents (e.g. mod, class, methd, func and attr). Default: False.
A boolean, or an explicit list of inherited members to render. If true, select all inherited members, which can then be filtered with members. If false or empty list, do not select any inherited member. Default: False.
members (list[str] | bool | None) \u2013
A boolean, or an explicit list of members to render. If true, select all members without further filtering. If false or empty list, do not render members. If none, select all members and apply further filtering with filters and docstrings. Default: None.
members_order (str) \u2013
The members ordering to use. Options: alphabetical - order by the members names, source - order members as they appear in the source file. Default: \"alphabetical\".
filters (list[str] | None) \u2013
A list of filters applied to filter objects based on their name. A filter starting with ! will exclude matching objects instead of including them. The members option takes precedence over filters (filters will still be applied recursively to lower members in the hierarchy). Default: [\"!^_[^_]\"].
group_by_category (bool) \u2013
Group the object's children by categories: attributes, classes, functions, and modules. Default: True.
show_submodules (bool) \u2013
When rendering a module, show its submodules recursively. Default: False.
summary (bool | dict[str, bool]) \u2013
Whether to render summaries of modules, classes, functions (methods) and attributes.
show_labels (bool) \u2013
Whether to show labels of the members. Default: True.
Docstrings options:
docstring_style (str) \u2013
The docstring style to use: google, numpy, sphinx, or None. Default: \"google\".
docstring_options (dict) \u2013
The options for the docstring parser. See parsers under griffe.docstrings.
docstring_section_style (str) \u2013
The style used to render docstring sections. Options: table, list, spacy. Default: \"table\".
merge_init_into_class (bool) \u2013
Whether to merge the __init__ method into the class' signature and docstring. Default: False.
show_if_no_docstring (bool) \u2013
Show the object heading even if it has no docstring or children with docstrings. Default: False.
show_docstring_attributes (bool) \u2013
Whether to display the \"Attributes\" section in the object's docstring. Default: True.
show_docstring_functions (bool) \u2013
Whether to display the \"Functions\" or \"Methods\" sections in the object's docstring. Default: True.
show_docstring_classes (bool) \u2013
Whether to display the \"Classes\" section in the object's docstring. Default: True.
show_docstring_modules (bool) \u2013
Whether to display the \"Modules\" section in the object's docstring. Default: True.
show_docstring_description (bool) \u2013
Whether to display the textual block (including admonitions) in the object's docstring. Default: True.
show_docstring_examples (bool) \u2013
Whether to display the \"Examples\" section in the object's docstring. Default: True.
show_docstring_other_parameters (bool) \u2013
Whether to display the \"Other Parameters\" section in the object's docstring. Default: True.
show_docstring_parameters (bool) \u2013
Whether to display the \"Parameters\" section in the object's docstring. Default: True.
show_docstring_raises (bool) \u2013
Whether to display the \"Raises\" section in the object's docstring. Default: True.
show_docstring_receives (bool) \u2013
Whether to display the \"Receives\" section in the object's docstring. Default: True.
show_docstring_returns (bool) \u2013
Whether to display the \"Returns\" section in the object's docstring. Default: True.
show_docstring_warns (bool) \u2013
Whether to display the \"Warns\" section in the object's docstring. Default: True.
show_docstring_yields (bool) \u2013
Whether to display the \"Yields\" section in the object's docstring. Default: True.
Signatures/annotations options:
annotations_path (str) \u2013
The verbosity for annotations path: brief (recommended), or source (as written in the source). Default: \"brief\".
line_length (int) \u2013
Maximum line length when formatting code/signatures. Default: 60.
show_signature (bool) \u2013
Show methods and functions signatures. Default: True.
show_signature_annotations (bool) \u2013
Show the type annotations in methods and functions signatures. Default: False.
signature_crossrefs (bool) \u2013
Whether to render cross-references for type annotations in signatures. Default: False.
separate_signature (bool) \u2013
Whether to put the whole signature in a code block below the heading. If Black is installed, the signature is also formatted using it. Default: False.
unwrap_annotated (bool) \u2013
Whether to unwrap Annotated types to show only the type without the annotations. Default: False.
modernize_annotations (bool) \u2013
Whether to modernize annotations, for example Optional[str] into str | None. Default: False.
There are multiple ways to tell the handler where to find your packages/modules.
The recommended method is to use the paths option, as it's the only one that works with the -f option of MkDocs, allowing to build the documentation from any location on the file system. Indeed, the paths provided with the paths option are computed as relative to the configuration file (mkdocs.yml), so that the current working directory has no impact on the build process: you can build the docs from any location on your filesystem.
"},{"location":"usage/#using-the-paths-option","title":"Using the paths option","text":"
Except for case 1, which is supported by default, we strongly recommend setting the path to your packages using this option, even if it works without it (for example because your project manager automatically adds src to PYTHONPATH), to make sure anyone can build your docs from any location on their filesystem.
"},{"location":"usage/#using-the-pythonpath-environment-variable","title":"Using the PYTHONPATH environment variable","text":"
This method has limitations.
This method might work for you, with your current setup, but not for others trying your build your docs with their own setup/environment. We recommend using the paths method instead.
You can take advantage of the usual Python loading mechanisms. In Bash and other shells, you can run your command like this (note the prepended PYTHONPATH=...):
"},{"location":"usage/#installing-your-package-in-the-current-python-environment","title":"Installing your package in the current Python environment","text":"
This method has limitations.
This method might work for you, with your current setup, but not for others trying your build your docs with their own setup/environment. We recommend using the paths method instead.
Install your package in the current environment, and run MkDocs:
Our templates add CSS classes to many HTML elements to make it possible for users to customize the resulting look and feel.
To add CSS rules and style mkdocstrings' output, put them in a CSS file in your docs folder, for example in docs/css/mkdocstrings.css, and reference this file in MkDocs' extra_css configuration option:
mkdocs.yml
extra_css:\n- css/mkdocstrings.css\n
Example:
docs/css/mkdocstrings.css
.doc-section-title {\n font-weight: bold;\n}\n
The following CSS classes are used in the generated HTML:
doc: on all the following elements
doc-children: on divs containing the children of an object
doc-object: on divs containing an object
doc-attribute: on divs containing an attribute
doc-class: on divs containing a class
doc-function: on divs containing a function
doc-module: on divs containing a module
doc-heading: on objects headings
doc-object-name: on spans wrapping objects names/paths in the heading
doc-KIND-name: as above, specific to the kind of object (module, class, function, attribute)
doc-contents: on divs wrapping the docstring then the children (if any)
first: same, but only on the root object's contents div
doc-labels: on spans wrapping the object's labels
doc-label: on small elements containing a label
doc-label-LABEL: same, where LABEL is replaced by the actual label
doc-section-title: on section titles (depend on the selected style for section rendering)
doc-section-item: on section items (depend on the selected style for section rendering)
doc-md-description: on divs containing HTML descriptions converted from Markdown docstrings
doc-symbol: on code tags of symbol types
doc-symbol-heading: on symbol types in headings
doc-symbol-toc: on symbol types in the ToC
doc-symbol-KIND: specific to the kind of object (module, class, function, method, attribute)
You can customize the colors of the symbol types (see show_symbol_type_heading and show_symbol_type_toc) by overriding the values of our CSS variables, for example:
The [data-md-color-scheme=\"*\"] selectors work with the Material for MkDocs theme. If you are using another theme, adapt the selectors to this theme if it supports light and dark themes, otherwise just override the variables at root level:
See them in the repository. See the general mkdocstrings documentation to learn how to override them: https://mkdocstrings.github.io/theming/#templates.
Each one of these templates extends a base version in theme/_base. Example:
theme/class.html
{% extends \"_base/class.html\" %}\n
Some of these templates define Jinja blocks. allowing to customize only parts of a template without having to fully copy-paste it into your project:
Only the templates for the Material for MkDocs provide Jinja blocks. The following tables show the block names, description, and the Jinja context available in their scope.
In docstring/attributes.html, docstring/functions.html, docstring/classes.html, docstring/modules.html, docstring/other_parameters.html, docstring/parameters.html, docstring/raises.html, docstring/receives.html, docstring/returns.html, docstring/warns.html, and docstring/yields.html:
table_style: The section as a table.
list_style: The section as a list.
spacy_style: The section as a Spacy table.
Available context:
section: The DocstringSection instance (see DocstringSection* subclasses).
"},{"location":"usage/customization/#syntax-highlight-in-signatures","title":"Syntax highlight in signatures","text":"
You can customize the colors in syntax highlighted signatures. If you are using the Material for MkDocs theme, here are some customization examples:
/* Fancier color for operators such as * and |. */\n.doc-signature .o {\n color: var(--md-code-hl-special-color);\n}\n\n/* Fancier color for constants such as None, True, and False. */\n.doc-signature .kc {\n color: var(--md-code-hl-constant-color);\n}\n\n/* Fancier color for built-in types (only useful when cross-references are used). */\n.doc-signature .n > a[href^=\"https://docs.python.org/\"][href*=\"/functions.html#\"],\n.doc-signature .n > a[href^=\"https://docs.python.org/\"][href*=\"/stdtypes.html#\"] {\n color: var(--md-code-hl-constant-color);\n}\n
For other themes, use their own CSS variables, or use plain colors such as violet or #2987f2.
"},{"location":"usage/extensions/","title":"Extensions","text":""},{"location":"usage/extensions/#work-in-progress","title":"Work in Progress!","text":"
The Python handler supports extensions through mkdocstrings' handler extensions.
Specifically, additional templates can be added to the handler, and Griffe extensions can instruct the handler to use a particular template for a particular object by setting a value in the Griffe object's extra dictionary:
griffe_extension.py
obj = ... # get a reference to a Griffe object\nif \"mkdocstrings\" not in obj.extra:\n obj.extra[\"mkdocstrings\"] = {}\nobj.extra[\"mkdocstrings\"][\"template\"] = \"template_name.html\"\n
Every style gets rendered the same way. Here are some docstring examples.
GoogleNumpySphinx
def greet(name: str) -> str:\n \"\"\"Greet someone.\n\n Parameters:\n name: The name of the person to greet.\n\n Returns:\n A greeting message.\n \"\"\"\n return f\"Hello {name}!\"\n
def greet(name: str) -> str:\n \"\"\"Greet someone.\n\n Parameters\n ----------\n name\n The name of the person to greet.\n\n Returns\n -------\n A greeting message.\n \"\"\"\n return f\"Hello {name}!\"\n
def greet(name: str) -> str:\n \"\"\"Greet someone.\n\n :param name: The name of the person to greet.\n :return: A greeting message.\n \"\"\"\n return f\"Hello {name}!\"\n
A section is a block of text that has a special meaning in a docstring. There are sections for documenting attributes of an object, parameters of a function, exceptions raised by a function, the return value of a function, etc.
Sections are parsed as structured data and can therefore be rendered in different ways. Possible values:
\"table\": a simple table, usually with type, name and description columns
\"list\": a simple list, akin to what you get with the ReadTheDocs Sphinx theme
\"spacy\": a poor implementation of the amazing tables in Spacy's documentation
Tables work well when you have lots of items with short names, type annotations, descriptions, etc.. With longer strings, the columns risk getting squished horizontally. In that case, the Spacy tables can help.
Parameters:
Type Name Description Default intthreshold Threshold for something. required boolflag Enable something. False
Other Parameters:
Type Name Description Default list[int | float]gravity_forces Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. required VacuumType | Literal[\"regular\"]vacuum_type Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. VacuumType.PLASMA
Lists work well whatever the length of names, type annotations, descriptions, etc.
Parameters:
threshold (int) \u2014 Threshold for something.
flag (bool) \u2014 Enable something.
Other Parameters:
gravity_forces (list[int | float]) \u2014 Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
vacuum_type (VacuumType | Literal[\"regular\"]) \u2014 Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Spacy tables work better than regular tables with longer names, type annotations, descriptions, etc., by reserving more horizontal space on the second column.
Parameters:
Name Description threshold Threshold for something.TYPE: int DEFAULT: required flag Enable something.TYPE: bool DEFAULT: False
Other Parameters:
Name Description gravity_forces Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.TYPE: list[int | float] DEFAULT: required vacuum_type Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.TYPE:VacuumType | Literal[\"regular\"] DEFAULT: VacuumType.PLASMA"},{"location":"usage/configuration/docstrings/#merge_init_into_class","title":"merge_init_into_classThing(value=0)Thing","text":"
Type boolFalse
Whether to merge the __init__ method into the class' signature and docstring.
By default, only the class name is rendered in headings. When merging, the __init__ method parameters are added after the class name, like a signature, and the __init__ method docstring is appended to the class' docstring. This option is well used in combination with the ignore_init_summary docstring option, to discard the first line of the __init__ docstring which is not often useful.
class Thing:\n \"\"\"A class for things.\"\"\"\n\n def __init__(self, value: int = 0):\n \"\"\"Initialize a thing.\n\n Parameters:\n value: The thing's value.\n \"\"\"\n self.value = value\n
Preview
Merged, summary discardedUnmerged, summary kept
Class docstring.
Parameters:
Type Name Description Default intvalue The thing's value. 0
Class docstring.
__init__(value=0)
Initialize a thing.
Parameters:
Type Name Description Default intvalue The thing's value. 0"},{"location":"usage/configuration/docstrings/#show_if_no_docstring","title":"show_if_no_docstringfunction_without_docstringfunction_with_docstringClassWithoutDocstringfunction_with_docstringClassWithoutDocstring","text":"
Type boolFalse
Show the object heading even if it has no docstring or children with docstrings.
Without an explicit list of members, members are selected based on filters, and then filtered again to keep only those with docstrings. Checking if a member has a docstring is done recursively: if at least one of its direct or indirect members (lower in the tree) has a docstring, the member is rendered. If the member does not have a docstring, and none of its members have a docstring, it is excluded.
With this option you can tell the Python handler to skip the docstring check.
class Class:\n \"\"\"Summary.\n\n Long description.\n\n Warning: Deprecated\n Stop using this class.\n\n Attributes:\n attr: Some attribute.\n \"\"\"\n\n attr: int = 1\n
Preview
With description blocksWithout description blocks
Summary.
Long description.
Deprecated
Stop using this class.
Attributes:
Type Name Description intattr Some attribute.
Attributes:
Type Name Description intattr Some attribute."},{"location":"usage/configuration/docstrings/#show_docstring_examples","title":"show_docstring_examplesprint_helloprint_hello","text":"
Type boolTrue
Whether to render the \"Examples\" section of docstrings.
def iter_skip(\n iterable: Iterable[T],\n initial_skip: int = 0,\n) -> Generator[T, int, None]:\n \"\"\"Iterate and skip elements.\n\n Receives:\n skip: Number of elements to skip.\n \"\"\"\n skip = initial_skip\n for element in iterable:\n if skip or 0 > 0:\n skip -= 1\n else:\n skip = yield element\n
def warn():\n \"\"\"Warn user.\n\n Warns:\n UserWarning: When this is inappropriate.\n \"\"\"\n warnings.warn(UserWarning(\"This is inappropriate\"))\n
Preview
With warningsWithout warnings
Warn user.
Warns:
Type Description UserWarning When this is inappropriate.
def iter_skip(\n iterable: Iterable[T],\n initial_skip: int = 0,\n) -> Generator[T, int, None]:\n \"\"\"Iterate and skip elements.\n\n Yields:\n Elements of the iterable.\n \"\"\"\n skip = initial_skip\n for element in iterable:\n if skip or 0 > 0:\n skip -= 1\n else:\n skip = yield element\n
Whether to allow inspecting modules (importing them) when it is not possible to visit them (parse their source code).
When loading data for a given package, Griffe discovers every Python module, compiled or not, and inspects or visits them accordingly.
If you have compiled modules but also provide stubs for them, you might want to disable the inspection of these modules, because inspection picks up many more members, and sometimes the collected data is inaccurate (depending on the tool that was used to compile the module) or too low-level/technical for API documentation.
Show the inheritance diagram of a class using Mermaid.
With this option enabled, an inheritance diagram (as a flowchart) will be displayed after a class signature. Each node will act as a cross-reference and will bring you to the relevant class' documentation when clicking on it.
It should work out of the box with Material for MkDocs. For other themes, you must include Mermaid's Javascript code manually:
Pre-load modules that are not specified directly in autodoc instructions (::: identifier). It is useful when you want to render documentation for a particular member of an object, and this member is imported from another package than its parent.
For an imported member to be rendered, you need to add it to the __all__ attribute of the importing module. The package from which the imported object originates must be accessible to the handler (see Finding modules).
When looking for documentation specified in autodoc instructions (::: identifier), also look for the stubs package as defined in PEP 561 if it exists. This is useful when most of your documentation is separately provided by such a package and not inline in your main package.
When injecting documentation for an object, the object itself and its members are rendered. For each layer of objects, we increase the heading level by 1.
The initial heading level will be used for the first layer. If you set it to 3, then headings will start with <h3>.
If the heading for the root object is not shown, then the initial heading level is used for its members.
Whether to render headings for function/method parameters.
With this option enabled, each function/method parameter (including parameters of __init__ methods merged in their parent class with the merge_init_into_class option) gets a permalink, an entry in the Table of Contents, and an entry in the generated objects inventory. The permalink and inventory entry allow cross-references from internal and external pages.
The identifier used in the permalink and inventory is of the following form: path.to.function(param_name). To manually cross-reference a parameter, you can therefore use this Markdown syntax:
- Class parameter: [`param`][package.module.Class(param)]\n- Method parameter: [`param`][package.module.Class.method(param)]\n- Function parameter: [`param`][package.module.function(param)]\n- Variadic positional parameters: [`*args`][package.module.function(*args)]\n- Variadic keyword parameters: [`**kwargs`][package.module.function(**kwargs)]\n
Enabling this option along with signature_crossrefs will automatically render cross-references to parameters in class/function/method signatures and attributes values.
Show the heading of the object at the root of the documentation tree (i.e. the object referenced by the identifier after :::).
It is pretty common to inject documentation for one module per page, especially when following our automatic reference pages recipe. Since each page already has a title, usually being the module's name, we can spare one heading level by not showing the heading for the module itself (heading levels are limited to 6 by the HTML specification).
Sparing that extra level can be helpful when your objects tree is deeply nested (e.g. method in a class in a class in a module). If your objects tree is not deeply nested, and you are injecting documentation for many different objects on a single page, it might be preferable to render the heading of each object.
If the root heading is not shown, at least add a ToC entry for it.
If you inject documentation for an object in the middle of a page, after long paragraphs, and without showing the root heading, then you will not be able to link to this particular object as it won't have a permalink and will be \"lost\" in the middle of text. In that case, it is useful to add a hidden anchor to the document, which will also appear in the table of contents.
In other cases, you might want to disable the entry to avoid polluting the ToC. It is not possible to show the root heading and hide the ToC entry.
Show the full Python path for the root object heading.
The path of a Python object is the dot-separated list of names under which it is accessible, for example package.module.Class.method.
With this option you can choose to show the full path of the object you inject documentation for, or just its name. This option impacts only the object you specify, not its members. For members, see the two other options show_root_members_full_path and show_object_full_path.
Same as for show_root_members_full_path, but for every member, recursively. This option takes precedence over show_root_members_full_path:
show_root_members_full_pathshow_object_full_path Direct root members path False False Name only False True Full True False Full True True Full in mkdocs.yml (global configuration)
When grouped by categories, show a heading for each category. These category headings will appear in the table of contents, allowing you to link to them using their permalinks.
Not recommended with deeply nested object
When injecting documentation for deeply nested objects, you'll quickly run out of heading levels, and the objects at the bottom of the tree risk all getting documented using H6 headings, which might decrease the readability of your API docs.
Only members declared in this list will be rendered. A member without a docstring will still be rendered, even if show_if_no_docstring is set to false.
The members will be rendered in the specified order, regardless of the value of members_order. Note that members will still be grouped by category, according to the group_by_category option.
Passing a falsy value (no, false in YAML) or an empty list ([]) will tell the Python handler not to render any member. Passing a truthy value (yes, true in YAML) will tell the Python handler to render every member.
Any given value, except for an explicit None (null in YAML) will tell the handler to ignore filters for the object's members. Filters will still be applied to the next layers of members (grand-children).
An explicit list of inherited members (for classes) to render.
Inherited members are always fetched from classes that are in the same package as the currently rendered class. To fetch members inherited from base classes, themselves coming from external packages, use the preload_modules option. For example, if your class inherits from Pydantic's BaseModel, and you want to render BaseModel's methods in your class, use preload_modules: [pydantic]. The pydantic package must be available in the current environment.
Passing a falsy value (no, false in YAML) or an empty list ([]) will tell the Python handler not to render any inherited member. Passing a truthy value (yes, true in YAML) will tell the Python handler to render every inherited member.
When all inherited members are selected with inherited_members: true, it is possible to specify both members and inherited members in the members list:
In this case, only declared members will be subject to further filtering with filters and docstrings.
inherited_members: true # (1)\n# members: null\n
In this case, both declared and inherited members will be subject to further filtering with filters and docstrings.
You can render all declared members and all or specific inherited members, avoiding further filtering with filters and docstrings by setting members: true:
source: order members as they appear in the source file.
The order applies for all members, recursively. The order will be ignored for members that are explicitely sorted using the members option. Note that members will still be grouped by category, according to the group_by_category option.
A list of filters applied to filter objects based on their name.
Filters are regular expressions. These regular expressions are evaluated by Python and so must match the syntax supported by the re module. A filter starting with ! (negative filter) will exclude matching objects instead of including them.
The default value ([\"!^_[^_]\"]) means: render every object, except those starting with one underscore, unless they start with two underscores. It means that an object whose name is hello, __hello, or __hello__ will be rendered, but not one whose name is _hello.
Each filter takes precedence over the previous one. This allows for fine-grain selection of objects by adding more specific filters. For example, you can start by unselecting objects that start with _, and add a second filter that re-select objects that start with __. The default filters can therefore be rewritten like this:
filters:\n- \"!^_\"\n- \"^__\"\n
If there are no negative filters, the handler considers that everything is unselected first, and then selects things based on your positive filters. If there is at least one negative filter, the handler considers that everything is selected first, and then re-selects/unselects things based on your other filters. In short, filters: [\"a\"] means \"keep nothing except names containing a\", while filters: [\"!a\"] means \"keep everything except names containing a\".
An empty list of filters tells the Python handler to render every object. The members option takes precedence over filters (filters will still be applied recursively to lower members in the hierarchy).
Group the object members by categories: attributes, classes, functions, and modules.
Members within a same category will be ordered according to the members_order option. You can use the show_category_heading option to also render a heading for each category.
When rendering a module, show its submodules recursively.
This is false by default, because most of the time we render only one module per page, and when rendering a package (a tree of modules and their members) on a single page, we quickly run out of heading levels.
Whether to render summaries of modules, classes, functions (methods) and attributes.
This option accepts a boolean (yes, true, no, false in YAML) or a dictionary with one or more of the following keys: attributes, functions, classes, modules, with booleans as values. Class methods summary is (de)activated with the functions key. By default, summary is false, and by extension all values are false.
Summaries will be rendered as the corresponding docstring sections. For example, the summary for attributes will be rendered as an Attributes docstring section. The section will be rendered in accordance with the docstring_section_style option. If the objects appearing in the summary are also rendered on the page (or somewhere else on the site), their name will automatically link to their rendered documentation.
brief (recommended): render only the last component of each type path, not their full paths. For example, it will render Sequence[Path] and not typing.Sequence[pathlib.Path]. Brief annotations will cross-reference the right object anyway, and show the full path in a tooltip when hovering them.
source: render annotations as written in the source. For example if you imported typing as t, it will render typing.Sequence as t.Sequence. Each part will cross-reference the relevant object: t will link to the typing module and Sequence will link to the Sequence type.
full: render annotations with their full path (the opposite of brief). For example if you import Sequence and Pattern from typing and annoate something using Sequence[Pattern], it will render as typing.Sequence[typing.Pattern], with each part cross-referencing the corresponding object.
import markdown\nimport markupsafe\n\n\ndef convert(text: str, md: markdown.Markdown) -> markupsafe.Markup:\n \"\"\"Convert text to Markdown.\n\n Parameters:\n text: The text to convert.\n md: A Markdown instance.\n\n Returns:\n Converted markup.\n \"\"\"\n return markupsafe.Markup(md.convert(text))\n
Convert text to Markdown.
Parameters:
Type Description Default str The text to convert. required Markdown A Markdown instance. required
Returns:
Type Name Description Markuptext Converted markup.
import markdown\nfrom markupsafe import Markup\n\n\ndef convert(text: str, md: markdown.Markdown) -> Markup:\n \"\"\"Convert text to Markdown.\n\n Parameters:\n text: The text to convert.\n md: A Markdown instance.\n\n Returns:\n Converted markup.\n \"\"\"\n return Markup(md.convert(text))\n
Convert text to Markdown.
Parameters:
Type Description Default str The text to convert. required markdown.Markdown A Markdown instance. required
Returns:
Type Name Description Markuptext Converted markup.
from markdown import Markdown\nfrom markupsafe import Markup\n\n\ndef convert(text: str, md: Markdown) -> Markup:\n \"\"\"Convert text to Markdown.\n\n Parameters:\n text: The text to convert.\n md: A Markdown instance.\n\n Returns:\n Converted markup.\n \"\"\"\n return Markup(md.convert(text))\n
Convert text to Markdown.
Parameters:
Type Description Default str The text to convert. required markdown.Markdown A Markdown instance. required
Returns:
Type Name Description markupsafe.Markuptext Converted markup."},{"location":"usage/configuration/signatures/#line_length","title":"line_lengthlong_function_namelong_function_name","text":"
Type int60
Maximum line length when formatting code/signatures.
When separating signatures from headings with the separate_signature option, the Python handler will try to format the signatures using Black and the specified line length.
If Black is not installed, the handler issues an INFO log once.
Sponsors only \u2014 Insiders 1.8.0 \u2014 This feature also requires Griffe Insiders to be installed.
Type boolFalse
Modernize annotations with latest features and PEPs of the Python language.
The Python language keeps evolving, and often library developers must continue to support a few minor versions of Python. Therefore they cannot use some features that were introduced in the latest versions.
Yet this doesn't mean they can't enjoy latest features in their docs: Griffe allows to \"modernize\" expressions, for example by replacing typing.Union with PEP 604 type unions |. Thanks to this, mkdocstrings' Python handler can automatically transform type annotations into their modern equivalent. This improves consistency in your docs, and shows users how to use your code with the latest features of the language.
Whether to render cross-references for type annotations in signatures.
When signatures are separated from headings with the separate_signature option and type annotations are shown with the show_signature_annotations option, this option will render a cross-reference (link) for each type annotation in the signature.
"},{"location":"usage/docstrings/google/","title":"Google style","text":""},{"location":"usage/docstrings/google/#work-in-progress","title":"Work in Progress!","text":""},{"location":"usage/docstrings/google/#google-style-admonitions","title":"Google-style admonitions","text":"
With Google-style docstrings, any section that is not recognized will be transformed into its admonition equivalent. For example:
DocstringResult
\"\"\"\nNote:\n It looks like a section, but it will be rendered as an admonition.\n\nTip: You can even choose a title.\n This admonition has a custom title!\n\"\"\"\n
Note
It looks like a section, but it will be rendered as an admonition.
You can even choose a title.
This admonition has a custom title!
See Napoleon's documentation. See the supported docstring sections on Griffe's documentation.
"},{"location":"usage/docstrings/numpy/","title":"Numpydoc style","text":""},{"location":"usage/docstrings/numpy/#work-in-progress","title":"Work in Progress!","text":"
Note
As Numpy-style is partially supported by the underlying parser, you may experience problems in the building process if your docstring has a Methods section in the class docstring (see #366).
See Numpydoc's documentation. See the supported docstring sections on Griffe's documentation.
"},{"location":"usage/docstrings/sphinx/","title":"Sphinx style","text":""},{"location":"usage/docstrings/sphinx/#work-in-progress","title":"Work in Progress!","text":"
See Sphinx's documentation. See the supported docstring sections on Griffe's documentation.
"}]}
\ No newline at end of file
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Overview","text":"mkdocstrings-python
A Python handler for mkdocstrings.
The Python handler uses Griffe to collect documentation from Python source code. The word \"griffe\" can sometimes be used instead of \"signature\" in French. Griffe is able to visit the Abstract Syntax Tree (AST) of the source code to extract useful information. It is also able to execute the code (by importing it) and introspect objects in memory when source code is not available. Finally, it can parse docstrings following different styles.
Data collection from source code: collection of the object-tree and the docstrings is done thanks to Griffe.
Support for type annotations: Griffe collects your type annotations and mkdocstrings uses them to display parameter types or return types. It is even able to automatically add cross-references to other objects from your API, from the standard library or third-party libraries! See how to load inventories to enable it.
Recursive documentation of Python objects: just use the module dotted-path as an identifier, and you get the full module docs. You don't need to inject documentation for each class, function, etc.
Support for documented attributes: attributes (variables) followed by a docstring (triple-quoted string) will be recognized by Griffe in modules, classes and even in __init__ methods.
Multiple docstring-styles support: common support for Google-style, Numpydoc-style, and Sphinx-style docstrings. See Griffe's documentation on docstrings support.
Admonition support in Google docstrings: blocks like Note: or Warning: will be transformed to their admonition equivalent. We do not support nested admonitions in docstrings!
Every object has a TOC entry: we render a heading for each object, meaning MkDocs picks them into the Table of Contents, which is nicely displayed by the Material theme. Thanks to mkdocstrings cross-reference ability, you can reference other objects within your docstrings, with the classic Markdown syntax: [this object][package.module.object] or directly with [package.module.object][]
Source code display: mkdocstrings can add a collapsible div containing the highlighted source code of the Python object.
Only filter out imported objects instead of non-public ones after applying filters (e2f4b35 by Timoth\u00e9e Mazzucotelli). Issue-mkdocstrings/griffe-294
Update code for Griffe 0.46 to avoid deprecation warnings (321b407 by Timoth\u00e9e Mazzucotelli).
Change load_external_modules default value to None to support new default mode in Griffe (ae5896c by Timoth\u00e9e Mazzucotelli).
Set handler's name (a71ab12 by Timoth\u00e9e Mazzucotelli).
Update *.html top-level templates to extend the *.html.jinja base templates (a8c540e by Timoth\u00e9e Mazzucotelli). Issue-151
Update *.html base templates to extend their *.html.jinja counterpart, while overriding the logs block to issue a logging message (info) stating that extending *.html templates is deprecated (e6f1b9c by Timoth\u00e9e Mazzucotelli). Issue-151
Add *.html.jinja top-level (overridable) templates, extending their base counterpart (7c14924 by Timoth\u00e9e Mazzucotelli). Issue-151
Add *.html.jinja base templates, which are copies of *.html templates, with an additional logs block, and using the updated get_template filter (eced9a5 by Timoth\u00e9e Mazzucotelli). Issue-151
Update get_template filter to support both *.html and *.html.jinja templates, logging a message (info) when *.html templates are overridden by users (3546fd7 by Timoth\u00e9e Mazzucotelli). Issue-151
Log a warning when base templates are overridden (26e3d66 by Timoth\u00e9e Mazzucotelli). Issue-151
Release Insiders features of the $500/month funding goal (bd30106 by Timoth\u00e9e Mazzucotelli). The features and projects related to mkdocstrings-python are:
Cross-references for type annotations in signatures
Symbol types in headings and table of contents
griffe-inherited-docstrings, a Griffe extension for inheriting docstrings
griffe2md, a tool to output API docs to Markdown using Griffe
See the complete list of features and projects here: https://pawamoy.github.io/insiders/#500-plasmavac-user-guide.
Show parameter default values within the \"list\" section style too (55f08f3 by Antoine Dechaume). PR #92, Co-authored-by: Timoth\u00e9e Mazzucotelli pawamoy@pm.me
The signature of the format_signature filter has changed. If you override templates in your project to customize the output, make sure to update the following templates so that they use the new filter signature:
class.html
expression.html
function.html
signature.html
You can see how to use the filter in this commit's changes: f686f4e4.
We take this as an opportunity to go out of beta and bump the version to 1.0.0. This will allow users to rely on semantic versioning.
Return all known anchors (9bbfe14 by Timoth\u00e9e Mazzucotelli).
Update for griffe 0.4.0 (831aabb by Timoth\u00e9e Mazzucotelli).
"},{"location":"code_of_conduct/","title":"Contributor Covenant Code of Conduct","text":""},{"location":"code_of_conduct/#our-pledge","title":"Our Pledge","text":"
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at dev@pawamoy.fr. All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the reporter of any incident.
Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
Community Impact: A violation through a single incident or series of actions.
Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
Community Impact: A serious violation of community standards, including sustained inappropriate behavior.
Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
Consequence: A permanent ban from any sort of public interaction within the community.
This Code of Conduct is adapted from the Contributor Covenant, version 2.1, available at https://www.contributor-covenant.org/version/2/1/code_of_conduct.html.
Community Impact Guidelines were inspired by Mozilla's code of conduct enforcement ladder.
For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.
This project uses duty to run tasks. A Makefile is also provided. The Makefile will try to run certain tasks on multiple Python versions. If for some reason you don't want to run the task on multiple Python versions, you run the task directly with make run duty TASK.
The Makefile detects if a virtual environment is activated, so make will work the same with the virtualenv activated or not.
If you work in VSCode, we provide an action to configure VSCode for the project.
Commit messages must follow our convention based on the Angular style or the Karma convention:
<type>[(scope)]: Subject\n\n[Body]\n
Subject and body must be valid Markdown. Subject must have proper casing (uppercase for first letter if it makes sense), but no dot at the end, and no punctuation in general.
Scope and body are optional. Type can be:
build: About packaging, building wheels, etc.
chore: About packaging or repo/files management.
ci: About Continuous Integration.
deps: Dependencies update.
docs: About documentation.
feat: New feature.
fix: Bug fix.
perf: About performance.
refactor: Changes that are not features or bug fixes.
style: A change in code style/format.
tests: About tests.
If you write a body, please add trailers at the end (for example issues and PR references, or co-authors), without relying on GitHub's flavored Markdown:
Body.\n\nIssue #10: https://github.com/namespace/project/issues/10\nRelated to PR namespace/other-project#15: https://github.com/namespace/other-project/pull/15\n
These \"trailers\" must appear at the end of the body, without any blank lines between them. The trailer title can contain any character except colons :. We expect a full URI for each trailer, not just GitHub autolinks (for example, full GitHub URLs for commits and issues, not the hash or the #issue-number).
We do not enforce a line length on commit messages summary and body, but please avoid very long summaries, and very long lines in the body, unless they are part of code blocks that must not be wrapped.
These projects were used to build mkdocstrings-python. Thank you!
Python | uv | copier-uv
"},{"location":"credits/#exec-1--runtime-dependencies","title":"Runtime dependencies","text":"Project Summary Version (accepted) Version (last resolved) License click Composable command line interface toolkit >=7.08.1.7 BSD-3-Clause colorama Cross-platform colored terminal text. >=0.40.4.6 BSD License ghp-import Copy your docs directly to the gh-pages branch. >=1.02.1.0 Apache Software License griffe Signatures for entire Python programs. Extract the structure, the frame, the skeleton of your project, to generate API documentation or find breaking changes in your API. >=0.480.48.0.1.2.0 ISC importlib_metadata Read metadata from Python packages >=4.6, >=4.48.2.0 Apache Software License Jinja2 A very fast and expressive template engine. >=2.11.1, >=2.103.1.4 BSD License Markdown Python implementation of John Gruber's Markdown. >=3.3.6, >=3.33.6 BSD License MarkupSafe Safely add untrusted strings to HTML/XML markup. >=2.0.1, >=1.12.1.5 BSD-3-Clause mergedeep A deep merge function for \ud83d\udc0d. >=1.3.41.3.4 MIT License mkdocs Project documentation with Markdown. >=1.6, >=1.41.6.0 BSD-2-Clause mkdocs-autorefs Automatically link across pages in MkDocs. >=0.3.11.0.1 ISC mkdocs-get-deps MkDocs extension that lists all dependencies according to a mkdocs.yml file >=0.2.00.2.0 MIT mkdocstrings Automatic documentation from sources, for MkDocs. >=0.250.25.2 ISC packaging Core utilities for Python packages >=24.0, >=20.524.1 Apache Software License + BSD License pathspec Utility library for gitignore style pattern matching of file paths. >=0.11.10.12.1 Mozilla Public License 2.0 (MPL 2.0) platformdirs A small Python package for determining appropriate platform-specific dirs, e.g. a user data dir. >=2.2.0, >=24.2.2 MIT pymdown-extensions Extension pack for Python Markdown. >=6.310.8.1 MIT python-dateutil Extensions to the standard Python datetime module >=2.8.12.9.0.post0 BSD License + Apache Software License PyYAML YAML parser and emitter for Python >=5.16.0.1 MIT pyyaml_env_tag A custom YAML tag for referencing environment variables in YAML files. >=0.10.1 MIT License six Python 2 and 3 compatibility utilities >=1.51.16.0 MIT typing_extensions Backported and Experimental Type Hints for Python 3.8+ >=4.1, >=4.0.14.12.2 Python Software Foundation License watchdog Filesystem events monitoring >=2.04.0.1 Apache-2.0 zipp Backport of pathlib-compatible object wrapper for zip files >=0.53.19.2 MIT License"},{"location":"credits/#exec-1--development-dependencies","title":"Development dependencies","text":"Project Summary Version (accepted) Version (last resolved) License ansimarkup Produce colored terminal text with an xml-like markup ~=1.41.5.0 Revised BSD License appdirs A small Python module for determining appropriate platform-specific dirs, e.g. a \"user data dir\". >=1.41.4.4 MIT Babel Internationalization utilities ~=2.102.15.0 BSD-3-Clause backports.tarfile Backport of CPython tarfile module 1.2.0 MIT License black The uncompromising code formatter. >=24.424.4.2 MIT build A simple, correct Python build frontend >=1.21.2.1 MIT License certifi Python package for providing Mozilla's CA Bundle. >=2017.4.172024.7.4 MPL-2.0 cffi Foreign Function Interface for Python calling C code. >=1.121.16.0 MIT charset-normalizer The Real First Universal Charset Detector. Open, modern and actively maintained alternative to Chardet. >=2, <43.3.2 MIT click Composable command line interface toolkit >=7.08.1.7 BSD-3-Clause colorama Cross-platform colored terminal text. >=0.40.4.6 BSD License coverage Code coverage measurement for Python >=5.2.17.6.0 Apache-2.0 cryptography cryptography is a package which provides cryptographic recipes and primitives to Python developers. >=2.043.0.0 Apache-2.0 OR BSD-3-Clause csscompressor A python port of YUI CSS Compressor >=0.9.50.9.5 BSD docutils Docutils -- Python Documentation Utilities >=0.21.20.21.2 Public Domain + Python Software Foundation License + BSD License + GNU General Public License (GPL) duty A simple task runner. >=1.41.4.0 ISC editables Editable installations >=0.50.5 MIT License execnet execnet: rapid multi-Python deployment >=2.12.1.1 MIT failprint Run a command, print its output only if it fails. >=0.11, !=1.0.01.0.2 ISC ghp-import Copy your docs directly to the gh-pages branch. >=1.02.1.0 Apache Software License git-changelog Automatic Changelog generator using Jinja2 templates. >=2.52.5.2 ISC gitdb Git Object Database >=4.0.1, <54.0.11 BSD License GitPython GitPython is a Python library used to interact with Git repositories 3.1.43 BSD-3-Clause htmlmin2 An HTML Minifier >=0.1.130.1.13 BSD idna Internationalized Domain Names in Applications (IDNA) >=2.5, <43.7 BSD License importlib_metadata Read metadata from Python packages >=4.6, >=4.48.2.0 Apache Software License iniconfig brain-dead simple config-ini parsing 2.0.0 MIT jaraco.classes Utility functions for Python class constructs 3.4.0 MIT License jaraco.context Useful decorators and context managers 5.3.0 MIT License jaraco.functools Functools like those found in stdlib 4.0.1 MIT License jeepney Low-level, pure Python DBus protocol wrapper. >=0.4.20.8.0 MIT License Jinja2 A very fast and expressive template engine. >=2.11.1, >=2.103.1.4 BSD License jsmin JavaScript minifier. >=3.0.13.0.1 MIT License keyring Store and access your passwords safely. >=15.125.2.1 MIT License Markdown Python implementation of John Gruber's Markdown. >=3.3.6, >=3.33.6 BSD License markdown-callouts Markdown extension: a classier syntax for admonitions >=0.40.4.0 MIT markdown-exec Utilities to execute code blocks in Markdown files. >=1.81.9.3.1.1.0 ISC markdown-it-py Python port of markdown-it. Markdown parsing, done right! >=2.2.03.0.0 MIT License MarkupSafe Safely add untrusted strings to HTML/XML markup. >=2.0.1, >=1.12.1.5 BSD-3-Clause mdurl Markdown URL utilities ~=0.10.1.2 MIT License mergedeep A deep merge function for \ud83d\udc0d. >=1.3.41.3.4 MIT License mkdocs Project documentation with Markdown. >=1.6, >=1.41.6.0 BSD-2-Clause mkdocs-autorefs Automatically link across pages in MkDocs. >=0.3.11.0.1 ISC mkdocs-coverage MkDocs plugin to integrate your coverage HTML report into your site. >=1.01.1.0 ISC mkdocs-gen-files MkDocs plugin to programmatically generate documentation pages during the build >=0.50.5.0 MIT mkdocs-get-deps MkDocs extension that lists all dependencies according to a mkdocs.yml file >=0.2.00.2.0 MIT mkdocs-git-committers-plugin-2 An MkDocs plugin to create a list of contributors on the page. The git-committers plugin will seed the template context with a list of GitHub or GitLab committers and other useful GIT info such as last modified date >=2.32.3.0 MIT mkdocs-literate-nav MkDocs plugin to specify the navigation in Markdown instead of YAML >=0.60.6.1 MIT mkdocs-material Documentation that simply works >=9.59.5.30+insiders.4.53.11 MIT mkdocs-material-extensions Extension pack for Python Markdown and MkDocs Material. ~=1.31.3.1 MIT mkdocs-minify-plugin An MkDocs plugin to minify HTML, JS or CSS files prior to being written to disk >=0.80.8.0 MIT mkdocstrings Automatic documentation from sources, for MkDocs. >=0.250.25.2 ISC more-itertools More routines for operating on iterables, beyond itertools 10.3.0 MIT License mypy Optional static typing for Python >=1.101.11.0 MIT mypy-extensions Type system extensions for programs checked with the mypy type checker. >=0.4.31.0.0 MIT License nh3 Python bindings to the ammonia HTML sanitization library. >=0.2.140.2.18 MIT packaging Core utilities for Python packages >=24.0, >=20.524.1 Apache Software License + BSD License paginate Divides large result sets into pages for easier browsing ~=0.50.5.6 MIT pathspec Utility library for gitignore style pattern matching of file paths. >=0.11.10.12.1 Mozilla Public License 2.0 (MPL 2.0) pkginfo Query metadata from sdists / bdists / installed packages. >=1.8.11.10.0 MIT platformdirs A small Python package for determining appropriate platform-specific dirs, e.g. a user data dir. >=2.2.0, >=24.2.2 MIT pluggy plugin and hook calling mechanisms for python >=1.5, <21.5.0 MIT ptyprocess Run a subprocess in a pseudo terminal ~=0.60.7.0 ISC License (ISCL) pycparser C parser in Python 2.22 BSD-3-Clause Pygments Pygments is a syntax highlighting package written in Python. ~=2.162.18.0 BSD-2-Clause pymdown-extensions Extension pack for Python Markdown. >=6.310.8.1 MIT pyproject_hooks Wrappers to call pyproject.toml-based build backend hooks. 1.1.0 MIT License pytest pytest: simple powerful testing with Python >=8.28.3.2 MIT pytest-cov Pytest plugin for measuring coverage. >=5.05.0.0 MIT pytest-randomly Pytest plugin to randomly order tests and control random.seed. >=3.153.15.0 MIT pytest-xdist pytest xdist plugin for distributed testing, most importantly across multiple CPUs >=3.63.6.1 MIT License python-dateutil Extensions to the standard Python datetime module >=2.8.12.9.0.post0 BSD License + Apache Software License PyYAML YAML parser and emitter for Python >=5.16.0.1 MIT pyyaml_env_tag A custom YAML tag for referencing environment variables in YAML files. >=0.10.1 MIT License readme_renderer readme_renderer is a library for rendering readme descriptions for Warehouse >=35.044.0 Apache License, Version 2.0 regex Alternative regular expression module, to replace re. >=2022.42024.7.24 Apache Software License requests Python HTTP for Humans. ~=2.262.32.3 Apache-2.0 requests-toolbelt A utility belt for advanced users of python-requests >=0.8.0, !=0.9.01.0.0 Apache 2.0 rfc3986 Validating URI References per RFC 3986 >=1.4.02.0.0 Apache 2.0 rich Render rich text, tables, progress bars, syntax highlighting, markdown and more to the terminal >=12.0.013.7.1 MIT ruff An extremely fast Python linter and code formatter, written in Rust. >=0.40.5.5 MIT SecretStorage Python bindings to FreeDesktop.org Secret Service API >=3.23.3.3 BSD 3-Clause License semver Python helper for Semantic Versioning (https://semver.org) >=2.133.0.2 BSD six Python 2 and 3 compatibility utilities >=1.51.16.0 MIT smmap A pure Python implementation of a sliding window memory map manager >=3.0.1, <65.0.1 BSD twine Collection of utilities for publishing packages on PyPI >=5.15.1.1 Apache Software License types-Markdown Typing stubs for Markdown >=3.63.6.0.20240316 Apache-2.0 license types-PyYAML Typing stubs for PyYAML >=6.06.0.12.20240724 Apache-2.0 license typing_extensions Backported and Experimental Type Hints for Python 3.8+ >=4.1, >=4.0.14.12.2 Python Software Foundation License urllib3 HTTP library with thread-safe connection pooling, file post, and more. >=1.21.1, <32.2.2 MIT License watchdog Filesystem events monitoring >=2.04.0.1 Apache-2.0 zipp Backport of pathlib-compatible object wrapper for zip files >=0.53.19.2 MIT License
ISC License\n\nCopyright (c) 2021, Timoth\u00e9e Mazzucotelli\n\nPermission to use, copy, modify, and/or distribute this software for any\npurpose with or without fee is hereby granted, provided that the above\ncopyright notice and this permission notice appear in all copies.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\" AND THE AUTHOR DISCLAIMS ALL WARRANTIES\nWITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF\nMERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR\nANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES\nWHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN\nACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF\nOR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.\n
mkdocstrings-python follows the sponsorware release strategy, which means that new features are first exclusively released to sponsors as part of Insiders. Read on to learn what sponsorships achieve, how to become a sponsor to get access to Insiders, and what's in it for you!
"},{"location":"insiders/#what-is-insiders","title":"What is Insiders?","text":"
mkdocstrings-python Insiders is a private fork of mkdocstrings-python, hosted as a private GitHub repository. Almost1 all new features are developed as part of this fork, which means that they are immediately available to all eligible sponsors, as they are made collaborators of this repository.
Every feature is tied to a funding goal in monthly subscriptions. When a funding goal is hit, the features that are tied to it are merged back into mkdocstrings-python and released for general availability, making them available to all users. Bugfixes are always released in tandem.
Sponsorships make this project sustainable, as they buy the maintainers of this project time \u2013 a very scarce resource \u2013 which is spent on the development of new features, bug fixing, stability improvement, issue triage and general support. The biggest bottleneck in Open Source is time.3
If you're unsure if you should sponsor this project, check out the list of completed funding goals to learn whether you're already using features that were developed with the help of sponsorships. You're most likely using at least a handful of them, thanks to our awesome sponsors!
"},{"location":"insiders/#whats-in-it-for-me","title":"What's in it for me?","text":"
The moment you become a sponsor, you'll get immediate access to 9 additional features that you can start using right away, and which are currently exclusively available to sponsors:
Class inheritance diagrams with Mermaid
Annotations modernization
Parameter headings
Automatic cross-references to parameters
Automatic cross-references for default parameter values in signatures
Automatic rendering of function signature overloads
Auto-summary of object members
griffe-warnings-deprecated \u2014 [Project] Griffe extension for @warnings.deprecated (PEP 702)
griffe-pydantic \u2014 [Project] Griffe extension for Pydantic
These are just the features related to this project. See the complete feature list on the author's main Insiders page.
"},{"location":"insiders/#how-to-become-a-sponsor","title":"How to become a sponsor","text":"
Thanks for your interest in sponsoring! In order to become an eligible sponsor with your GitHub account, visit pawamoy's sponsor profile, and complete a sponsorship of $10 a month or more. You can use your individual or organization GitHub account for sponsoring.
Important: If you're sponsoring @pawamoy through a GitHub organization, please send a short email to insiders@pawamoy.fr with the name of your organization and the GitHub account of the individual that should be added as a collaborator.4
You can cancel your sponsorship anytime.5
\u00a0 Join our awesome sponsors
If you sponsor publicly, you're automatically added here with a link to your profile and avatar to show your support for mkdocstrings-python. Alternatively, if you wish to keep your sponsorship private, you'll be a silent +1. You can select visibility during checkout and change it afterwards.
The following section lists all funding goals. Each goal contains a list of features prefixed with a checkmark symbol, denoting whether a feature is already available or planned, but not yet implemented. When the funding goal is hit, the features are released for general availability.
This section lists all funding goals that were previously completed, which means that those features were part of Insiders, but are now generally available and can be used by all users.
"},{"location":"insiders/#500-plasmavac-user-guide","title":"$ 500 \u2014 PlasmaVac User Guide","text":"
Cross-references for type annotations in signatures
Symbol types in headings and table of contents
griffe-inherited-docstrings \u2014 [Project] Griffe extension for inheriting docstrings
We're building an open source project and want to allow outside collaborators to use mkdocstrings-python locally without having access to Insiders. Is this still possible?
Yes. Insiders is compatible with mkdocstrings-python. Almost all new features and configuration options are either backward-compatible or implemented behind feature flags. Most Insiders features enhance the overall experience, though while these features add value for the users of your project, they shouldn't be necessary for previewing when making changes to content.
We don't want to pay for sponsorship every month. Are there any other options?
Yes. You can sponsor on a yearly basis by switching your GitHub account to a yearly billing cycle. If for some reason you cannot do that, you could also create a dedicated GitHub account with a yearly billing cycle, which you only use for sponsoring (some sponsors already do that).
If you have any problems or further questions, please reach out to insiders@pawamoy.fr.
Are we allowed to use Insiders under the same terms and conditions as mkdocstrings-python?
Yes. Whether you're an individual or a company, you may use mkdocstrings-python Insiders precisely under the same terms as mkdocstrings-python, which are given by the ISC License. However, we kindly ask you to respect our fair use policy:
Please don't distribute the source code of Insiders. You may freely use it for public, private or commercial projects, privately fork or mirror it, but please don't make the source code public, as it would counteract the sponsorware strategy.
If you cancel your subscription, you're automatically removed as a collaborator and will miss out on all future updates of Insiders. However, you may use the latest version that's available to you as long as you like. Just remember that GitHub deletes private forks.
In general, every new feature is first exclusively released to sponsors, but sometimes upstream dependencies enhance existing features that must be supported by mkdocstrings-python.\u00a0\u21a9
Note that $10 a month is the minimum amount to become eligible for Insiders. While GitHub Sponsors also allows to sponsor lower amounts or one-time amounts, those can't be granted access to Insiders due to technical reasons. Such contributions are still very much welcome as they help ensuring the project's sustainability.\u00a0\u21a9
Making an Open Source project sustainable is exceptionally hard: maintainers burn out, projects are abandoned. That's not great and very unpredictable. The sponsorware model ensures that if you decide to use mkdocstrings-python, you can be sure that bugs are fixed quickly and new features are added regularly.\u00a0\u21a9
It's currently not possible to grant access to each member of an organization, as GitHub only allows for adding users. Thus, after sponsoring, please send an email to insiders@pawamoy.fr, stating which account should become a collaborator of the Insiders repository. We're working on a solution which will make access to organizations much simpler. To ensure that access is not tied to a particular individual GitHub account, create a bot account (i.e. a GitHub account that is not tied to a specific individual), and use this account for the sponsoring. After being added to the list of collaborators, the bot account can create a private fork of the private Insiders GitHub repository, and grant access to all members of the organizations.\u00a0\u21a9
If you cancel your sponsorship, GitHub schedules a cancellation request which will become effective at the end of the billing cycle. This means that even though you cancel your sponsorship, you will keep your access to Insiders as long as your cancellation isn't effective. All charges are processed by GitHub through Stripe. As we don't receive any information regarding your payment, and GitHub doesn't offer refunds, sponsorships are non-refundable.\u00a0\u21a9
"},{"location":"insiders/changelog/","title":"Changelog","text":""},{"location":"insiders/changelog/#mkdocstrings-python-insiders","title":"mkdocstrings-python Insiders","text":""},{"location":"insiders/changelog/#1.8.3","title":"1.8.3 June 19, 2024","text":"
Update code for Griffe 0.46+ to avoid deprecation warnings
"},{"location":"insiders/changelog/#1.8.2","title":"1.8.2 May 09, 2024","text":"
Don't render cross-refs for default values when signatures aren't separated
"},{"location":"insiders/changelog/#1.8.1","title":"1.8.1 April 19, 2024","text":"
Render enumeration instance name instead of just \"value\", allowing proper cross-reference
"},{"location":"insiders/changelog/#1.8.0","title":"1.8.0 March 24, 2024","text":"
Annotations modernization
"},{"location":"insiders/changelog/#1.7.0","title":"1.7.0 March 24, 2024","text":"
Class inheritance diagrams with Mermaid
"},{"location":"insiders/changelog/#1.6.0","title":"1.6.0 January 30, 2024","text":"
Render cross-references to parameters documentation in signatures and attribute values.
Add parameter_headings option to render headings for parameters (enabling permalinks and ToC/inventory entries).
Render cross-references for default parameter values in signatures.
"},{"location":"insiders/changelog/#1.5.1","title":"1.5.1 September 12, 2023","text":"
Prevent empty auto-summarized Methods section.
"},{"location":"insiders/changelog/#1.5.0","title":"1.5.0 September 05, 2023","text":"
Render function signature overloads.
"},{"location":"insiders/changelog/#1.4.0","title":"1.4.0 August 27, 2023","text":"
Render cross-references in attribute signatures.
"},{"location":"insiders/changelog/#1.3.0","title":"1.3.0 August 24, 2023","text":"
Add \"method\" symbol type.
"},{"location":"insiders/changelog/#1.2.0","title":"1.2.0 August 20, 2023","text":"
Add member auto-summaries.
"},{"location":"insiders/changelog/#1.1.4","title":"1.1.4 July 17, 2023","text":"
Fix heading level increment for class members.
"},{"location":"insiders/changelog/#1.1.3","title":"1.1.3 July 17, 2023","text":"
Fix heading level (avoid with clause preventing to decrease it).
"},{"location":"insiders/changelog/#1.1.2","title":"1.1.2 July 15, 2023","text":"
Use non-breaking spaces after symbol types.
"},{"location":"insiders/changelog/#1.1.1","title":"1.1.1 June 27, 2023","text":"
Correctly escape expressions in signatures and other rendered types.
"},{"location":"insiders/changelog/#1.1.0","title":"1.1.0 June 4, 2023","text":"
Add Symbol types in headings and table of contents.
"},{"location":"insiders/changelog/#1.0.0","title":"1.0.0 May 10, 2023","text":"
Add cross-references for type annotations in signatures. Make sure to update your local templates as the signature of the format_signature filter has changed. The templates that must be updated: class.html, expression.html, function.html and signature.html.
"},{"location":"insiders/installation/","title":"Getting started with Insiders","text":"
mkdocstrings-python Insiders is a compatible drop-in replacement for mkdocstrings-python, and can be installed similarly using pip or git. Note that in order to access the Insiders repository, you need to become an eligible sponsor of @pawamoy on GitHub.
PyPI Insiders is a tool that helps you keep up-to-date versions of Insiders projects in the PyPI index of your choice (self-hosted, Google registry, Artifactory, etc.).
See how to install it and how to use it.
We kindly ask that you do not upload the distributions to public registries, as it is against our Terms of use.
The GH_TOKEN environment variable is a GitHub token. It can be obtained by creating a personal access token for your GitHub account. It will give you access to the Insiders repository, programmatically, from the command line or GitHub Actions workflows:
Go to https://github.com/settings/tokens
Click on Generate a new token
Enter a name and select the repo scope
Generate the token and store it in a safe place
Note that the personal access token must be kept secret at all times, as it allows the owner to access your private repositories.
When upgrading Insiders, you should always check the version of mkdocstrings-python which makes up the first part of the version qualifier. For example, a version like 8.x.x.4.x.x means that Insiders 4.x.x is currently based on 8.x.x.
If the major version increased, it's a good idea to consult the changelog and go through the steps to ensure your configuration is up to date and all necessary changes have been made.
Whether to load stubs package (package-stubs) when extracting docstrings. Default False.
allow_inspection (bool) \u2013
Whether to allow inspecting modules when visiting them is not possible. Default: True.
show_bases (bool) \u2013
Show the base classes of a class. Default: True.
show_inheritance_diagram (bool) \u2013
Show the inheritance diagram of a class using Mermaid. Default: False.
show_source (bool) \u2013
Show the source code of this object. Default: True.
preload_modules (list[str] | None) \u2013
Pre-load modules that are not specified directly in autodoc instructions (::: identifier). It is useful when you want to render documentation for a particular member of an object, and this member is imported from another package than its parent.
For an imported member to be rendered, you need to add it to the __all__ attribute of the importing module.
The modules must be listed as an array of strings. Default: None.
Headings options:
heading_level (int) \u2013
The initial heading level to use. Default: 2.
parameter_headings (bool) \u2013
Whether to render headings for parameters (therefore showing parameters in the ToC). Default: False.
show_root_heading (bool) \u2013
Show the heading of the object at the root of the documentation tree (i.e. the object referenced by the identifier after :::). Default: False.
show_root_toc_entry (bool) \u2013
If the root heading is not shown, at least add a ToC entry for it. Default: True.
show_root_full_path (bool) \u2013
Show the full Python path for the root object heading. Default: True.
show_root_members_full_path (bool) \u2013
Show the full Python path of the root members. Default: False.
show_object_full_path (bool) \u2013
Show the full Python path of every object. Default: False.
show_category_heading (bool) \u2013
When grouped by categories, show a heading for each category. Default: False.
show_symbol_type_heading (bool) \u2013
Show the symbol type in headings (e.g. mod, class, meth, func and attr). Default: False.
show_symbol_type_toc (bool) \u2013
Show the symbol type in the Table of Contents (e.g. mod, class, methd, func and attr). Default: False.
A boolean, or an explicit list of inherited members to render. If true, select all inherited members, which can then be filtered with members. If false or empty list, do not select any inherited member. Default: False.
members (list[str] | bool | None) \u2013
A boolean, or an explicit list of members to render. If true, select all members without further filtering. If false or empty list, do not render members. If none, select all members and apply further filtering with filters and docstrings. Default: None.
members_order (str) \u2013
The members ordering to use. Options: alphabetical - order by the members names, source - order members as they appear in the source file. Default: \"alphabetical\".
filters (list[str] | None) \u2013
A list of filters applied to filter objects based on their name. A filter starting with ! will exclude matching objects instead of including them. The members option takes precedence over filters (filters will still be applied recursively to lower members in the hierarchy). Default: [\"!^_[^_]\"].
group_by_category (bool) \u2013
Group the object's children by categories: attributes, classes, functions, and modules. Default: True.
show_submodules (bool) \u2013
When rendering a module, show its submodules recursively. Default: False.
summary (bool | dict[str, bool]) \u2013
Whether to render summaries of modules, classes, functions (methods) and attributes.
show_labels (bool) \u2013
Whether to show labels of the members. Default: True.
Docstrings options:
docstring_style (str) \u2013
The docstring style to use: google, numpy, sphinx, or None. Default: \"google\".
docstring_options (dict) \u2013
The options for the docstring parser. See docstring parsers and their options in Griffe docs.
docstring_section_style (str) \u2013
The style used to render docstring sections. Options: table, list, spacy. Default: \"table\".
merge_init_into_class (bool) \u2013
Whether to merge the __init__ method into the class' signature and docstring. Default: False.
show_if_no_docstring (bool) \u2013
Show the object heading even if it has no docstring or children with docstrings. Default: False.
show_docstring_attributes (bool) \u2013
Whether to display the \"Attributes\" section in the object's docstring. Default: True.
show_docstring_functions (bool) \u2013
Whether to display the \"Functions\" or \"Methods\" sections in the object's docstring. Default: True.
show_docstring_classes (bool) \u2013
Whether to display the \"Classes\" section in the object's docstring. Default: True.
show_docstring_modules (bool) \u2013
Whether to display the \"Modules\" section in the object's docstring. Default: True.
show_docstring_description (bool) \u2013
Whether to display the textual block (including admonitions) in the object's docstring. Default: True.
show_docstring_examples (bool) \u2013
Whether to display the \"Examples\" section in the object's docstring. Default: True.
show_docstring_other_parameters (bool) \u2013
Whether to display the \"Other Parameters\" section in the object's docstring. Default: True.
show_docstring_parameters (bool) \u2013
Whether to display the \"Parameters\" section in the object's docstring. Default: True.
show_docstring_raises (bool) \u2013
Whether to display the \"Raises\" section in the object's docstring. Default: True.
show_docstring_receives (bool) \u2013
Whether to display the \"Receives\" section in the object's docstring. Default: True.
show_docstring_returns (bool) \u2013
Whether to display the \"Returns\" section in the object's docstring. Default: True.
show_docstring_warns (bool) \u2013
Whether to display the \"Warns\" section in the object's docstring. Default: True.
show_docstring_yields (bool) \u2013
Whether to display the \"Yields\" section in the object's docstring. Default: True.
Signatures/annotations options:
annotations_path (str) \u2013
The verbosity for annotations path: brief (recommended), or source (as written in the source). Default: \"brief\".
line_length (int) \u2013
Maximum line length when formatting code/signatures. Default: 60.
show_signature (bool) \u2013
Show methods and functions signatures. Default: True.
show_signature_annotations (bool) \u2013
Show the type annotations in methods and functions signatures. Default: False.
signature_crossrefs (bool) \u2013
Whether to render cross-references for type annotations in signatures. Default: False.
separate_signature (bool) \u2013
Whether to put the whole signature in a code block below the heading. If Black is installed, the signature is also formatted using it. Default: False.
unwrap_annotated (bool) \u2013
Whether to unwrap Annotated types to show only the type without the annotations. Default: False.
modernize_annotations (bool) \u2013
Whether to modernize annotations, for example Optional[str] into str | None. Default: False.
Filters to apply, based on members' names. Each element is a tuple: a pattern, and a boolean indicating whether to reject the object if the pattern matches.
An optional, explicit list of members to keep. When given and empty, return an empty list. When given and not empty, ignore filters and docstrings presence/absence.
You can install this handler as a mkdocstrings extra:
pyproject.toml
# PEP 621 dependencies declaration\n# adapt to your dependencies manager\n[project]\ndependencies = [\n \"mkdocstrings[python]>=0.18\",\n]\n
You can also explicitly depend on the handler:
pyproject.toml
# PEP 621 dependencies declaration\n# adapt to your dependencies manager\n[project]\ndependencies = [\n \"mkdocstrings-python\",\n]\n
The Python handler is the default mkdocstrings handler. You can change the default handler, or explicitely set the Python handler as default by defining the default_handler configuration option of mkdocstrings in mkdocs.yml:
With the Python handler installed and configured as default handler, you can inject documentation for a module, class, function, or any other Python object with mkdocstrings' autodoc syntax, in your Markdown pages:
::: path.to.object\n
If another handler was defined as default handler, you can explicitely ask for the Python handler to be used when injecting documentation with the handler option:
This option is used to import Sphinx-compatible objects inventories from other documentation sites. For example, you can import the standard library objects inventory like this:
When importing an inventory, you enable automatic cross-references to other documentation sites like the standard library docs or any third-party package docs. Typically, you want to import the inventories of your project's dependencies, at least those that are used in the public API.
See mkdocstrings' documentation on inventories for more details.
Additionally, the Python handler accepts a domains option in the import items, which allows to select the inventory domains to select. By default the Python handler only selects the py domain (for Python objects). You might find useful to also enable the std domain:
This option is used to provide filesystem paths in which to search for Python modules. Non-absolute paths are computed as relative to MkDocs configuration file. Example:
mkdocs.yml
plugins:\n- mkdocstrings:\n handlers:\n python:\n paths: [src] # search packages in the src folder\n
This option allows resolving aliases (imports) to any external module. Modules are considered external when they are not part of the package your are injecting documentation for. Setting this option to True will tell the handler to resolve aliases recursively when they are made public through the __all__ variable. By default, the handler will only resolve aliases when they point at a private sibling of the source package, for example aliases going from ast to _ast. Set load_external_modules to False to prevent even that.
Use with caution
This can load a lot of modules through Griffe, slowing down your build or triggering errors that Griffe does not yet handle. We recommend using the preload_modules option instead, which acts as an include-list rather than as include-all.
These options affect how the documentation is collected from sources and rendered. See the following tables summarizing the options, and get more details for each option in the following pages:
General options: various options that do not fit in the other categories
Headings options: options related to headings and the table of contents (or sidebar, depending on the theme used)
Members options: options related to filtering or ordering members in the generated documentation
Docstrings options: options related to docstrings (parsing and rendering)
Signature options: options related to signatures and type annotations
Whether to load stubs package (package-stubs) when extracting docstrings. Default False.
allow_inspection (bool) \u2013
Whether to allow inspecting modules when visiting them is not possible. Default: True.
show_bases (bool) \u2013
Show the base classes of a class. Default: True.
show_inheritance_diagram (bool) \u2013
Show the inheritance diagram of a class using Mermaid. Default: False.
show_source (bool) \u2013
Show the source code of this object. Default: True.
preload_modules (list[str] | None) \u2013
Pre-load modules that are not specified directly in autodoc instructions (::: identifier). It is useful when you want to render documentation for a particular member of an object, and this member is imported from another package than its parent.
For an imported member to be rendered, you need to add it to the __all__ attribute of the importing module.
The modules must be listed as an array of strings. Default: None.
Headings options:
heading_level (int) \u2013
The initial heading level to use. Default: 2.
parameter_headings (bool) \u2013
Whether to render headings for parameters (therefore showing parameters in the ToC). Default: False.
show_root_heading (bool) \u2013
Show the heading of the object at the root of the documentation tree (i.e. the object referenced by the identifier after :::). Default: False.
show_root_toc_entry (bool) \u2013
If the root heading is not shown, at least add a ToC entry for it. Default: True.
show_root_full_path (bool) \u2013
Show the full Python path for the root object heading. Default: True.
show_root_members_full_path (bool) \u2013
Show the full Python path of the root members. Default: False.
show_object_full_path (bool) \u2013
Show the full Python path of every object. Default: False.
show_category_heading (bool) \u2013
When grouped by categories, show a heading for each category. Default: False.
show_symbol_type_heading (bool) \u2013
Show the symbol type in headings (e.g. mod, class, meth, func and attr). Default: False.
show_symbol_type_toc (bool) \u2013
Show the symbol type in the Table of Contents (e.g. mod, class, methd, func and attr). Default: False.
A boolean, or an explicit list of inherited members to render. If true, select all inherited members, which can then be filtered with members. If false or empty list, do not select any inherited member. Default: False.
members (list[str] | bool | None) \u2013
A boolean, or an explicit list of members to render. If true, select all members without further filtering. If false or empty list, do not render members. If none, select all members and apply further filtering with filters and docstrings. Default: None.
members_order (str) \u2013
The members ordering to use. Options: alphabetical - order by the members names, source - order members as they appear in the source file. Default: \"alphabetical\".
filters (list[str] | None) \u2013
A list of filters applied to filter objects based on their name. A filter starting with ! will exclude matching objects instead of including them. The members option takes precedence over filters (filters will still be applied recursively to lower members in the hierarchy). Default: [\"!^_[^_]\"].
group_by_category (bool) \u2013
Group the object's children by categories: attributes, classes, functions, and modules. Default: True.
show_submodules (bool) \u2013
When rendering a module, show its submodules recursively. Default: False.
summary (bool | dict[str, bool]) \u2013
Whether to render summaries of modules, classes, functions (methods) and attributes.
show_labels (bool) \u2013
Whether to show labels of the members. Default: True.
Docstrings options:
docstring_style (str) \u2013
The docstring style to use: google, numpy, sphinx, or None. Default: \"google\".
docstring_options (dict) \u2013
The options for the docstring parser. See docstring parsers and their options in Griffe docs.
docstring_section_style (str) \u2013
The style used to render docstring sections. Options: table, list, spacy. Default: \"table\".
merge_init_into_class (bool) \u2013
Whether to merge the __init__ method into the class' signature and docstring. Default: False.
show_if_no_docstring (bool) \u2013
Show the object heading even if it has no docstring or children with docstrings. Default: False.
show_docstring_attributes (bool) \u2013
Whether to display the \"Attributes\" section in the object's docstring. Default: True.
show_docstring_functions (bool) \u2013
Whether to display the \"Functions\" or \"Methods\" sections in the object's docstring. Default: True.
show_docstring_classes (bool) \u2013
Whether to display the \"Classes\" section in the object's docstring. Default: True.
show_docstring_modules (bool) \u2013
Whether to display the \"Modules\" section in the object's docstring. Default: True.
show_docstring_description (bool) \u2013
Whether to display the textual block (including admonitions) in the object's docstring. Default: True.
show_docstring_examples (bool) \u2013
Whether to display the \"Examples\" section in the object's docstring. Default: True.
show_docstring_other_parameters (bool) \u2013
Whether to display the \"Other Parameters\" section in the object's docstring. Default: True.
show_docstring_parameters (bool) \u2013
Whether to display the \"Parameters\" section in the object's docstring. Default: True.
show_docstring_raises (bool) \u2013
Whether to display the \"Raises\" section in the object's docstring. Default: True.
show_docstring_receives (bool) \u2013
Whether to display the \"Receives\" section in the object's docstring. Default: True.
show_docstring_returns (bool) \u2013
Whether to display the \"Returns\" section in the object's docstring. Default: True.
show_docstring_warns (bool) \u2013
Whether to display the \"Warns\" section in the object's docstring. Default: True.
show_docstring_yields (bool) \u2013
Whether to display the \"Yields\" section in the object's docstring. Default: True.
Signatures/annotations options:
annotations_path (str) \u2013
The verbosity for annotations path: brief (recommended), or source (as written in the source). Default: \"brief\".
line_length (int) \u2013
Maximum line length when formatting code/signatures. Default: 60.
show_signature (bool) \u2013
Show methods and functions signatures. Default: True.
show_signature_annotations (bool) \u2013
Show the type annotations in methods and functions signatures. Default: False.
signature_crossrefs (bool) \u2013
Whether to render cross-references for type annotations in signatures. Default: False.
separate_signature (bool) \u2013
Whether to put the whole signature in a code block below the heading. If Black is installed, the signature is also formatted using it. Default: False.
unwrap_annotated (bool) \u2013
Whether to unwrap Annotated types to show only the type without the annotations. Default: False.
modernize_annotations (bool) \u2013
Whether to modernize annotations, for example Optional[str] into str | None. Default: False.
There are multiple ways to tell the handler where to find your packages/modules.
The recommended method is to use the paths option, as it's the only one that works with the -f option of MkDocs, allowing to build the documentation from any location on the file system. Indeed, the paths provided with the paths option are computed as relative to the configuration file (mkdocs.yml), so that the current working directory has no impact on the build process: you can build the docs from any location on your filesystem.
"},{"location":"usage/#using-the-paths-option","title":"Using the paths option","text":"
Except for case 1, which is supported by default, we strongly recommend setting the path to your packages using this option, even if it works without it (for example because your project manager automatically adds src to PYTHONPATH), to make sure anyone can build your docs from any location on their filesystem.
"},{"location":"usage/#using-the-pythonpath-environment-variable","title":"Using the PYTHONPATH environment variable","text":"
This method has limitations.
This method might work for you, with your current setup, but not for others trying your build your docs with their own setup/environment. We recommend using the paths method instead.
You can take advantage of the usual Python loading mechanisms. In Bash and other shells, you can run your command like this (note the prepended PYTHONPATH=...):
"},{"location":"usage/#installing-your-package-in-the-current-python-environment","title":"Installing your package in the current Python environment","text":"
This method has limitations.
This method might work for you, with your current setup, but not for others trying your build your docs with their own setup/environment. We recommend using the paths method instead.
Install your package in the current environment, and run MkDocs:
Our templates add CSS classes to many HTML elements to make it possible for users to customize the resulting look and feel.
To add CSS rules and style mkdocstrings' output, put them in a CSS file in your docs folder, for example in docs/css/mkdocstrings.css, and reference this file in MkDocs' extra_css configuration option:
mkdocs.yml
extra_css:\n- css/mkdocstrings.css\n
Example:
docs/css/mkdocstrings.css
.doc-section-title {\n font-weight: bold;\n}\n
The following CSS classes are used in the generated HTML:
doc: on all the following elements
doc-children: on divs containing the children of an object
doc-object: on divs containing an object
doc-attribute: on divs containing an attribute
doc-class: on divs containing a class
doc-function: on divs containing a function
doc-module: on divs containing a module
doc-heading: on objects headings
doc-object-name: on spans wrapping objects names/paths in the heading
doc-KIND-name: as above, specific to the kind of object (module, class, function, attribute)
doc-contents: on divs wrapping the docstring then the children (if any)
first: same, but only on the root object's contents div
doc-labels: on spans wrapping the object's labels
doc-label: on small elements containing a label
doc-label-LABEL: same, where LABEL is replaced by the actual label
doc-section-title: on section titles (depend on the selected style for section rendering)
doc-section-item: on section items (depend on the selected style for section rendering)
doc-md-description: on divs containing HTML descriptions converted from Markdown docstrings
doc-symbol: on code tags of symbol types
doc-symbol-heading: on symbol types in headings
doc-symbol-toc: on symbol types in the ToC
doc-symbol-KIND: specific to the kind of object (module, class, function, method, attribute)
You can customize the colors of the symbol types (see show_symbol_type_heading and show_symbol_type_toc) by overriding the values of our CSS variables, for example:
The [data-md-color-scheme=\"*\"] selectors work with the Material for MkDocs theme. If you are using another theme, adapt the selectors to this theme if it supports light and dark themes, otherwise just override the variables at root level:
See them in the repository. See the general mkdocstrings documentation to learn how to override them: https://mkdocstrings.github.io/theming/#templates.
Each one of these templates extends a base version in theme/_base. Example:
theme/class.html
{% extends \"_base/class.html\" %}\n
Some of these templates define Jinja blocks. allowing to customize only parts of a template without having to fully copy-paste it into your project:
Only the templates for the Material for MkDocs provide Jinja blocks. The following tables show the block names, description, and the Jinja context available in their scope.
In docstring/attributes.html, docstring/functions.html, docstring/classes.html, docstring/modules.html, docstring/other_parameters.html, docstring/parameters.html, docstring/raises.html, docstring/receives.html, docstring/returns.html, docstring/warns.html, and docstring/yields.html:
table_style: The section as a table.
list_style: The section as a list.
spacy_style: The section as a Spacy table.
Available context:
section: The DocstringSection instance (see DocstringSection* subclasses).
"},{"location":"usage/customization/#syntax-highlight-in-signatures","title":"Syntax highlight in signatures","text":"
You can customize the colors in syntax highlighted signatures. If you are using the Material for MkDocs theme, here are some customization examples:
/* Fancier color for operators such as * and |. */\n.doc-signature .o {\n color: var(--md-code-hl-special-color);\n}\n\n/* Fancier color for constants such as None, True, and False. */\n.doc-signature .kc {\n color: var(--md-code-hl-constant-color);\n}\n\n/* Fancier color for built-in types (only useful when cross-references are used). */\n.doc-signature .n > a[href^=\"https://docs.python.org/\"][href*=\"/functions.html#\"],\n.doc-signature .n > a[href^=\"https://docs.python.org/\"][href*=\"/stdtypes.html#\"] {\n color: var(--md-code-hl-constant-color);\n}\n
For other themes, use their own CSS variables, or use plain colors such as violet or #2987f2.
"},{"location":"usage/extensions/","title":"Extensions","text":""},{"location":"usage/extensions/#work-in-progress","title":"Work in Progress!","text":"
The Python handler supports extensions through mkdocstrings' handler extensions.
Specifically, additional templates can be added to the handler, and Griffe extensions can instruct the handler to use a particular template for a particular object by setting a value in the Griffe object's extra dictionary:
griffe_extension.py
obj = ... # get a reference to a Griffe object\nif \"mkdocstrings\" not in obj.extra:\n obj.extra[\"mkdocstrings\"] = {}\nobj.extra[\"mkdocstrings\"][\"template\"] = \"template_name.html\"\n
Every style gets rendered the same way. Here are some docstring examples.
GoogleNumpySphinx
def greet(name: str) -> str:\n \"\"\"Greet someone.\n\n Parameters:\n name: The name of the person to greet.\n\n Returns:\n A greeting message.\n \"\"\"\n return f\"Hello {name}!\"\n
def greet(name: str) -> str:\n \"\"\"Greet someone.\n\n Parameters\n ----------\n name\n The name of the person to greet.\n\n Returns\n -------\n A greeting message.\n \"\"\"\n return f\"Hello {name}!\"\n
def greet(name: str) -> str:\n \"\"\"Greet someone.\n\n :param name: The name of the person to greet.\n :return: A greeting message.\n \"\"\"\n return f\"Hello {name}!\"\n
A section is a block of text that has a special meaning in a docstring. There are sections for documenting attributes of an object, parameters of a function, exceptions raised by a function, the return value of a function, etc.
Sections are parsed as structured data and can therefore be rendered in different ways. Possible values:
\"table\": a simple table, usually with type, name and description columns
\"list\": a simple list, akin to what you get with the ReadTheDocs Sphinx theme
\"spacy\": a poor implementation of the amazing tables in Spacy's documentation
Tables work well when you have lots of items with short names, type annotations, descriptions, etc.. With longer strings, the columns risk getting squished horizontally. In that case, the Spacy tables can help.
Parameters:
Type Name Description Default intthreshold Threshold for something. required boolflag Enable something. False
Other Parameters:
Type Name Description Default list[int | float]gravity_forces Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. required VacuumType | Literal[\"regular\"]vacuum_type Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. VacuumType.PLASMA
Lists work well whatever the length of names, type annotations, descriptions, etc.
Parameters:
threshold (int) \u2014 Threshold for something.
flag (bool) \u2014 Enable something.
Other Parameters:
gravity_forces (list[int | float]) \u2014 Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
vacuum_type (VacuumType | Literal[\"regular\"]) \u2014 Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Spacy tables work better than regular tables with longer names, type annotations, descriptions, etc., by reserving more horizontal space on the second column.
Parameters:
Name Description threshold Threshold for something.TYPE: int DEFAULT: required flag Enable something.TYPE: bool DEFAULT: False
Other Parameters:
Name Description gravity_forces Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.TYPE: list[int | float] DEFAULT: required vacuum_type Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.TYPE:VacuumType | Literal[\"regular\"] DEFAULT: VacuumType.PLASMA"},{"location":"usage/configuration/docstrings/#merge_init_into_class","title":"merge_init_into_classThing(value=0)Thing","text":"
Type boolFalse
Whether to merge the __init__ method into the class' signature and docstring.
By default, only the class name is rendered in headings. When merging, the __init__ method parameters are added after the class name, like a signature, and the __init__ method docstring is appended to the class' docstring. This option is well used in combination with the ignore_init_summary docstring option, to discard the first line of the __init__ docstring which is not often useful.
class Thing:\n \"\"\"A class for things.\"\"\"\n\n def __init__(self, value: int = 0):\n \"\"\"Initialize a thing.\n\n Parameters:\n value: The thing's value.\n \"\"\"\n self.value = value\n
Preview
Merged, summary discardedUnmerged, summary kept
Class docstring.
Parameters:
Type Name Description Default intvalue The thing's value. 0
Class docstring.
__init__(value=0)
Initialize a thing.
Parameters:
Type Name Description Default intvalue The thing's value. 0"},{"location":"usage/configuration/docstrings/#show_if_no_docstring","title":"show_if_no_docstringfunction_without_docstringfunction_with_docstringClassWithoutDocstringfunction_with_docstringClassWithoutDocstring","text":"
Type boolFalse
Show the object heading even if it has no docstring or children with docstrings.
Without an explicit list of members, members are selected based on filters, and then filtered again to keep only those with docstrings. Checking if a member has a docstring is done recursively: if at least one of its direct or indirect members (lower in the tree) has a docstring, the member is rendered. If the member does not have a docstring, and none of its members have a docstring, it is excluded.
With this option you can tell the Python handler to skip the docstring check.
class Class:\n \"\"\"Summary.\n\n Long description.\n\n Warning: Deprecated\n Stop using this class.\n\n Attributes:\n attr: Some attribute.\n \"\"\"\n\n attr: int = 1\n
Preview
With description blocksWithout description blocks
Summary.
Long description.
Deprecated
Stop using this class.
Attributes:
Type Name Description intattr Some attribute.
Attributes:
Type Name Description intattr Some attribute."},{"location":"usage/configuration/docstrings/#show_docstring_examples","title":"show_docstring_examplesprint_helloprint_hello","text":"
Type boolTrue
Whether to render the \"Examples\" section of docstrings.
def iter_skip(\n iterable: Iterable[T],\n initial_skip: int = 0,\n) -> Generator[T, int, None]:\n \"\"\"Iterate and skip elements.\n\n Receives:\n skip: Number of elements to skip.\n \"\"\"\n skip = initial_skip\n for element in iterable:\n if skip or 0 > 0:\n skip -= 1\n else:\n skip = yield element\n
def warn():\n \"\"\"Warn user.\n\n Warns:\n UserWarning: When this is inappropriate.\n \"\"\"\n warnings.warn(UserWarning(\"This is inappropriate\"))\n
Preview
With warningsWithout warnings
Warn user.
Warns:
Type Description UserWarning When this is inappropriate.
def iter_skip(\n iterable: Iterable[T],\n initial_skip: int = 0,\n) -> Generator[T, int, None]:\n \"\"\"Iterate and skip elements.\n\n Yields:\n Elements of the iterable.\n \"\"\"\n skip = initial_skip\n for element in iterable:\n if skip or 0 > 0:\n skip -= 1\n else:\n skip = yield element\n
Whether to allow inspecting modules (importing them) when it is not possible to visit them (parse their source code).
When loading data for a given package, Griffe discovers every Python module, compiled or not, and inspects or visits them accordingly.
If you have compiled modules but also provide stubs for them, you might want to disable the inspection of these modules, because inspection picks up many more members, and sometimes the collected data is inaccurate (depending on the tool that was used to compile the module) or too low-level/technical for API documentation.
Show the inheritance diagram of a class using Mermaid.
With this option enabled, an inheritance diagram (as a flowchart) will be displayed after a class signature. Each node will act as a cross-reference and will bring you to the relevant class' documentation when clicking on it.
It should work out of the box with Material for MkDocs. For other themes, you must include Mermaid's Javascript code manually:
Pre-load modules that are not specified directly in autodoc instructions (::: identifier). It is useful when you want to render documentation for a particular member of an object, and this member is imported from another package than its parent.
For an imported member to be rendered, you need to add it to the __all__ attribute of the importing module. The package from which the imported object originates must be accessible to the handler (see Finding modules).
When looking for documentation specified in autodoc instructions (::: identifier), also look for the stubs package as defined in PEP 561 if it exists. This is useful when most of your documentation is separately provided by such a package and not inline in your main package.
When injecting documentation for an object, the object itself and its members are rendered. For each layer of objects, we increase the heading level by 1.
The initial heading level will be used for the first layer. If you set it to 3, then headings will start with <h3>.
If the heading for the root object is not shown, then the initial heading level is used for its members.
Whether to render headings for function/method parameters.
With this option enabled, each function/method parameter (including parameters of __init__ methods merged in their parent class with the merge_init_into_class option) gets a permalink, an entry in the Table of Contents, and an entry in the generated objects inventory. The permalink and inventory entry allow cross-references from internal and external pages.
The identifier used in the permalink and inventory is of the following form: path.to.function(param_name). To manually cross-reference a parameter, you can therefore use this Markdown syntax:
- Class parameter: [`param`][package.module.Class(param)]\n- Method parameter: [`param`][package.module.Class.method(param)]\n- Function parameter: [`param`][package.module.function(param)]\n- Variadic positional parameters: [`*args`][package.module.function(*args)]\n- Variadic keyword parameters: [`**kwargs`][package.module.function(**kwargs)]\n
Enabling this option along with signature_crossrefs will automatically render cross-references to parameters in class/function/method signatures and attributes values.
Show the heading of the object at the root of the documentation tree (i.e. the object referenced by the identifier after :::).
It is pretty common to inject documentation for one module per page, especially when following our automatic reference pages recipe. Since each page already has a title, usually being the module's name, we can spare one heading level by not showing the heading for the module itself (heading levels are limited to 6 by the HTML specification).
Sparing that extra level can be helpful when your objects tree is deeply nested (e.g. method in a class in a class in a module). If your objects tree is not deeply nested, and you are injecting documentation for many different objects on a single page, it might be preferable to render the heading of each object.
If the root heading is not shown, at least add a ToC entry for it.
If you inject documentation for an object in the middle of a page, after long paragraphs, and without showing the root heading, then you will not be able to link to this particular object as it won't have a permalink and will be \"lost\" in the middle of text. In that case, it is useful to add a hidden anchor to the document, which will also appear in the table of contents.
In other cases, you might want to disable the entry to avoid polluting the ToC. It is not possible to show the root heading and hide the ToC entry.
Show the full Python path for the root object heading.
The path of a Python object is the dot-separated list of names under which it is accessible, for example package.module.Class.method.
With this option you can choose to show the full path of the object you inject documentation for, or just its name. This option impacts only the object you specify, not its members. For members, see the two other options show_root_members_full_path and show_object_full_path.
Same as for show_root_members_full_path, but for every member, recursively. This option takes precedence over show_root_members_full_path:
show_root_members_full_pathshow_object_full_path Direct root members path False False Name only False True Full True False Full True True Full in mkdocs.yml (global configuration)
When grouped by categories, show a heading for each category. These category headings will appear in the table of contents, allowing you to link to them using their permalinks.
Not recommended with deeply nested object
When injecting documentation for deeply nested objects, you'll quickly run out of heading levels, and the objects at the bottom of the tree risk all getting documented using H6 headings, which might decrease the readability of your API docs.
Only members declared in this list will be rendered. A member without a docstring will still be rendered, even if show_if_no_docstring is set to false.
The members will be rendered in the specified order, regardless of the value of members_order. Note that members will still be grouped by category, according to the group_by_category option.
Passing a falsy value (no, false in YAML) or an empty list ([]) will tell the Python handler not to render any member. Passing a truthy value (yes, true in YAML) will tell the Python handler to render every member.
Any given value, except for an explicit None (null in YAML) will tell the handler to ignore filters for the object's members. Filters will still be applied to the next layers of members (grand-children).
An explicit list of inherited members (for classes) to render.
Inherited members are always fetched from classes that are in the same package as the currently rendered class. To fetch members inherited from base classes, themselves coming from external packages, use the preload_modules option. For example, if your class inherits from Pydantic's BaseModel, and you want to render BaseModel's methods in your class, use preload_modules: [pydantic]. The pydantic package must be available in the current environment.
Passing a falsy value (no, false in YAML) or an empty list ([]) will tell the Python handler not to render any inherited member. Passing a truthy value (yes, true in YAML) will tell the Python handler to render every inherited member.
When all inherited members are selected with inherited_members: true, it is possible to specify both members and inherited members in the members list:
In this case, only declared members will be subject to further filtering with filters and docstrings.
inherited_members: true # (1)\n# members: null\n
In this case, both declared and inherited members will be subject to further filtering with filters and docstrings.
You can render all declared members and all or specific inherited members, avoiding further filtering with filters and docstrings by setting members: true:
source: order members as they appear in the source file.
The order applies for all members, recursively. The order will be ignored for members that are explicitely sorted using the members option. Note that members will still be grouped by category, according to the group_by_category option.
A list of filters applied to filter objects based on their name.
Filters are regular expressions. These regular expressions are evaluated by Python and so must match the syntax supported by the re module. A filter starting with ! (negative filter) will exclude matching objects instead of including them.
The default value ([\"!^_[^_]\"]) means: render every object, except those starting with one underscore, unless they start with two underscores. It means that an object whose name is hello, __hello, or __hello__ will be rendered, but not one whose name is _hello.
Each filter takes precedence over the previous one. This allows for fine-grain selection of objects by adding more specific filters. For example, you can start by unselecting objects that start with _, and add a second filter that re-select objects that start with __. The default filters can therefore be rewritten like this:
filters:\n- \"!^_\"\n- \"^__\"\n
If there are no negative filters, the handler considers that everything is unselected first, and then selects things based on your positive filters. If there is at least one negative filter, the handler considers that everything is selected first, and then re-selects/unselects things based on your other filters. In short, filters: [\"a\"] means \"keep nothing except names containing a\", while filters: [\"!a\"] means \"keep everything except names containing a\".
An empty list of filters tells the Python handler to render every object. The members option takes precedence over filters (filters will still be applied recursively to lower members in the hierarchy).
Group the object members by categories: attributes, classes, functions, and modules.
Members within a same category will be ordered according to the members_order option. You can use the show_category_heading option to also render a heading for each category.
When rendering a module, show its submodules recursively.
This is false by default, because most of the time we render only one module per page, and when rendering a package (a tree of modules and their members) on a single page, we quickly run out of heading levels.
Whether to render summaries of modules, classes, functions (methods) and attributes.
This option accepts a boolean (yes, true, no, false in YAML) or a dictionary with one or more of the following keys: attributes, functions, classes, modules, with booleans as values. Class methods summary is (de)activated with the functions key. By default, summary is false, and by extension all values are false.
Summaries will be rendered as the corresponding docstring sections. For example, the summary for attributes will be rendered as an Attributes docstring section. The section will be rendered in accordance with the docstring_section_style option. If the objects appearing in the summary are also rendered on the page (or somewhere else on the site), their name will automatically link to their rendered documentation.
brief (recommended): render only the last component of each type path, not their full paths. For example, it will render Sequence[Path] and not typing.Sequence[pathlib.Path]. Brief annotations will cross-reference the right object anyway, and show the full path in a tooltip when hovering them.
source: render annotations as written in the source. For example if you imported typing as t, it will render typing.Sequence as t.Sequence. Each part will cross-reference the relevant object: t will link to the typing module and Sequence will link to the Sequence type.
full: render annotations with their full path (the opposite of brief). For example if you import Sequence and Pattern from typing and annoate something using Sequence[Pattern], it will render as typing.Sequence[typing.Pattern], with each part cross-referencing the corresponding object.
import markdown\nimport markupsafe\n\n\ndef convert(text: str, md: markdown.Markdown) -> markupsafe.Markup:\n \"\"\"Convert text to Markdown.\n\n Parameters:\n text: The text to convert.\n md: A Markdown instance.\n\n Returns:\n Converted markup.\n \"\"\"\n return markupsafe.Markup(md.convert(text))\n
Convert text to Markdown.
Parameters:
Type Description Default str The text to convert. required Markdown A Markdown instance. required
Returns:
Type Name Description Markuptext Converted markup.
import markdown\nfrom markupsafe import Markup\n\n\ndef convert(text: str, md: markdown.Markdown) -> Markup:\n \"\"\"Convert text to Markdown.\n\n Parameters:\n text: The text to convert.\n md: A Markdown instance.\n\n Returns:\n Converted markup.\n \"\"\"\n return Markup(md.convert(text))\n
Convert text to Markdown.
Parameters:
Type Description Default str The text to convert. required markdown.Markdown A Markdown instance. required
Returns:
Type Name Description Markuptext Converted markup.
from markdown import Markdown\nfrom markupsafe import Markup\n\n\ndef convert(text: str, md: Markdown) -> Markup:\n \"\"\"Convert text to Markdown.\n\n Parameters:\n text: The text to convert.\n md: A Markdown instance.\n\n Returns:\n Converted markup.\n \"\"\"\n return Markup(md.convert(text))\n
Convert text to Markdown.
Parameters:
Type Description Default str The text to convert. required markdown.Markdown A Markdown instance. required
Returns:
Type Name Description markupsafe.Markuptext Converted markup."},{"location":"usage/configuration/signatures/#line_length","title":"line_lengthlong_function_namelong_function_name","text":"
Type int60
Maximum line length when formatting code/signatures.
When separating signatures from headings with the separate_signature option, the Python handler will try to format the signatures using Black and the specified line length.
If Black is not installed, the handler issues an INFO log once.
Sponsors only \u2014 Insiders 1.8.0 \u2014 This feature also requires Griffe Insiders to be installed.
Type boolFalse
Modernize annotations with latest features and PEPs of the Python language.
The Python language keeps evolving, and often library developers must continue to support a few minor versions of Python. Therefore they cannot use some features that were introduced in the latest versions.
Yet this doesn't mean they can't enjoy latest features in their docs: Griffe allows to \"modernize\" expressions, for example by replacing typing.Union with PEP 604 type unions |. Thanks to this, mkdocstrings' Python handler can automatically transform type annotations into their modern equivalent. This improves consistency in your docs, and shows users how to use your code with the latest features of the language.
Whether to render cross-references for type annotations in signatures.
When signatures are separated from headings with the separate_signature option and type annotations are shown with the show_signature_annotations option, this option will render a cross-reference (link) for each type annotation in the signature.
"},{"location":"usage/docstrings/google/","title":"Google style","text":""},{"location":"usage/docstrings/google/#work-in-progress","title":"Work in Progress!","text":""},{"location":"usage/docstrings/google/#google-style-admonitions","title":"Google-style admonitions","text":"
With Google-style docstrings, any section that is not recognized will be transformed into its admonition equivalent. For example:
DocstringResult
\"\"\"\nNote:\n It looks like a section, but it will be rendered as an admonition.\n\nTip: You can even choose a title.\n This admonition has a custom title!\n\"\"\"\n
Note
It looks like a section, but it will be rendered as an admonition.
You can even choose a title.
This admonition has a custom title!
See Napoleon's documentation. See the supported docstring sections on Griffe's documentation.
"},{"location":"usage/docstrings/numpy/","title":"Numpydoc style","text":""},{"location":"usage/docstrings/numpy/#work-in-progress","title":"Work in Progress!","text":"
Note
As Numpy-style is partially supported by the underlying parser, you may experience problems in the building process if your docstring has a Methods section in the class docstring (see #366).
See Numpydoc's documentation. See the supported docstring sections on Griffe's documentation.
"},{"location":"usage/docstrings/sphinx/","title":"Sphinx style","text":""},{"location":"usage/docstrings/sphinx/#work-in-progress","title":"Work in Progress!","text":"
See Sphinx's documentation. See the supported docstring sections on Griffe's documentation.
\ No newline at end of file
diff --git a/usage/configuration/general/index.html b/usage/configuration/general/index.html
index b53b02fb..c11f783c 100644
--- a/usage/configuration/general/index.html
+++ b/usage/configuration/general/index.html
@@ -1,4 +1,4 @@
- General - mkdocstrings-python
Whether to allow inspecting modules (importing them) when it is not possible to visit them (parse their source code).
When loading data for a given package, Griffe discovers every Python module, compiled or not, and inspects or visits them accordingly.
If you have compiled modules but also provide stubs for them, you might want to disable the inspection of these modules, because inspection picks up many more members, and sometimes the collected data is inaccurate (depending on the tool that was used to compile the module) or too low-level/technical for API documentation.
Whether to allow inspecting modules (importing them) when it is not possible to visit them (parse their source code).
When loading data for a given package, Griffe discovers every Python module, compiled or not, and inspects or visits them accordingly.
If you have compiled modules but also provide stubs for them, you might want to disable the inspection of these modules, because inspection picks up many more members, and sometimes the collected data is inaccurate (depending on the tool that was used to compile the module) or too low-level/technical for API documentation.
in mkdocs.yml (global configuration)
plugins:-mkdocstrings:handlers:python:
@@ -104,4 +104,4 @@
...# rest of your code
-
Preview
your_func
Function docstring
your_func
\ No newline at end of file
+
Preview
your_func
Function docstring
your_func
\ No newline at end of file
diff --git a/usage/configuration/headings/index.html b/usage/configuration/headings/index.html
index 7317c315..6d99a539 100644
--- a/usage/configuration/headings/index.html
+++ b/usage/configuration/headings/index.html
@@ -1,4 +1,4 @@
- Headings - mkdocstrings-python
When injecting documentation for an object, the object itself and its members are rendered. For each layer of objects, we increase the heading level by 1.
The initial heading level will be used for the first layer. If you set it to 3, then headings will start with <h3>.
When injecting documentation for an object, the object itself and its members are rendered. For each layer of objects, we increase the heading level by 1.
The initial heading level will be used for the first layer. If you set it to 3, then headings will start with <h3>.
\ No newline at end of file
diff --git a/usage/configuration/members/index.html b/usage/configuration/members/index.html
index 0261488b..45b802d8 100644
--- a/usage/configuration/members/index.html
+++ b/usage/configuration/members/index.html
@@ -1,4 +1,4 @@
- Members - mkdocstrings-python
Only members declared in this list will be rendered. A member without a docstring will still be rendered, even if show_if_no_docstring is set to false.
The members will be rendered in the specified order, regardless of the value of members_order. Note that members will still be grouped by category, according to the group_by_category option.
Passing a falsy value (no, false in YAML) or an empty list ([]) will tell the Python handler not to render any member. Passing a truthy value (yes, true in YAML) will tell the Python handler to render every member.
Any given value, except for an explicit None (null in YAML) will tell the handler to ignore filters for the object's members. Filters will still be applied to the next layers of members (grand-children).
Only members declared in this list will be rendered. A member without a docstring will still be rendered, even if show_if_no_docstring is set to false.
The members will be rendered in the specified order, regardless of the value of members_order. Note that members will still be grouped by category, according to the group_by_category option.
Passing a falsy value (no, false in YAML) or an empty list ([]) will tell the Python handler not to render any member. Passing a truthy value (yes, true in YAML) will tell the Python handler to render every member.
Any given value, except for an explicit None (null in YAML) will tell the handler to ignore filters for the object's members. Filters will still be applied to the next layers of members (grand-children).
Whether to render summaries of modules, classes, functions (methods) and attributes.
This option accepts a boolean (yes, true, no, false in YAML) or a dictionary with one or more of the following keys: attributes, functions, classes, modules, with booleans as values. Class methods summary is (de)activated with the functions key. By default, summary is false, and by extension all values are false.
Examples:
summary:true
summary:false
summary:
@@ -190,4 +190,4 @@
show_labels: false
package/module.py
classSomeClass:some_attr:int
-
Preview
some_attr:intinstance-attribute
some_attr:int
\ No newline at end of file
+
Preview
some_attr:intinstance-attribute
some_attr:int
\ No newline at end of file
diff --git a/usage/configuration/signatures/index.html b/usage/configuration/signatures/index.html
index aa00eba0..52ed297e 100644
--- a/usage/configuration/signatures/index.html
+++ b/usage/configuration/signatures/index.html
@@ -1,4 +1,4 @@
- Signatures - mkdocstrings-python
brief (recommended): render only the last component of each type path, not their full paths. For example, it will render Sequence[Path] and not typing.Sequence[pathlib.Path]. Brief annotations will cross-reference the right object anyway, and show the full path in a tooltip when hovering them.
source: render annotations as written in the source. For example if you imported typing as t, it will render typing.Sequence as t.Sequence. Each part will cross-reference the relevant object: t will link to the typing module and Sequence will link to the Sequence type.
full: render annotations with their full path (the opposite of brief). For example if you import Sequence and Pattern from typing and annoate something using Sequence[Pattern], it will render as typing.Sequence[typing.Pattern], with each part cross-referencing the corresponding object.
brief (recommended): render only the last component of each type path, not their full paths. For example, it will render Sequence[Path] and not typing.Sequence[pathlib.Path]. Brief annotations will cross-reference the right object anyway, and show the full path in a tooltip when hovering them.
source: render annotations as written in the source. For example if you imported typing as t, it will render typing.Sequence as t.Sequence. Each part will cross-reference the relevant object: t will link to the typing module and Sequence will link to the Sequence type.
full: render annotations with their full path (the opposite of brief). For example if you import Sequence and Pattern from typing and annoate something using Sequence[Pattern], it will render as typing.Sequence[typing.Pattern], with each part cross-referencing the corresponding object.
Our templates add CSS classes to many HTML elements to make it possible for users to customize the resulting look and feel.
To add CSS rules and style mkdocstrings' output, put them in a CSS file in your docs folder, for example in docs/css/mkdocstrings.css, and reference this file in MkDocs' extra_css configuration option:
Our templates add CSS classes to many HTML elements to make it possible for users to customize the resulting look and feel.
To add CSS rules and style mkdocstrings' output, put them in a CSS file in your docs folder, for example in docs/css/mkdocstrings.css, and reference this file in MkDocs' extra_css configuration option:
Only the templates for the Material for MkDocs provide Jinja blocks. The following tables show the block names, description, and the Jinja context available in their scope.
Only the templates for the Material for MkDocs provide Jinja blocks. The following tables show the block names, description, and the Jinja context available in their scope.
You can customize the colors in syntax highlighted signatures. If you are using the Material for MkDocs theme, here are some customization examples:
/* Fancier color for operators such as * and |. */.doc-signature.o{color:var(--md-code-hl-special-color);}
@@ -254,4 +254,4 @@
padding-left:25px;border-left:.05remsolidrgba(200,200,200,0.2);}
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/usage/docstrings/google/index.html b/usage/docstrings/google/index.html
index f5ca85c4..ea7e3f1a 100644
--- a/usage/docstrings/google/index.html
+++ b/usage/docstrings/google/index.html
@@ -1,8 +1,8 @@
- Google - mkdocstrings-python
As Numpy-style is partially supported by the underlying parser, you may experience problems in the building process if your docstring has a Methods section in the class docstring (see #366).
As Numpy-style is partially supported by the underlying parser, you may experience problems in the building process if your docstring has a Methods section in the class docstring (see #366).
Specifically, additional templates can be added to the handler, and Griffe extensions can instruct the handler to use a particular template for a particular object by setting a value in the Griffe object's extra dictionary:
griffe_extension.py
obj=...# get a reference to a Griffe object
+ Extensions - mkdocstrings-python
Specifically, additional templates can be added to the handler, and Griffe extensions can instruct the handler to use a particular template for a particular object by setting a value in the Griffe object's extra dictionary:
griffe_extension.py
obj=...# get a reference to a Griffe objectif"mkdocstrings"notinobj.extra:obj.extra["mkdocstrings"]={}obj.extra["mkdocstrings"]["template"]="template_name.html"
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/usage/index.html b/usage/index.html
index bd13fb16..4ce474a5 100644
--- a/usage/index.html
+++ b/usage/index.html
@@ -1,4 +1,4 @@
- Usage - mkdocstrings-python
These options affect how the documentation is collected from sources and rendered. See the following tables summarizing the options, and get more details for each option in the following pages:
General options: various options that do not fit in the other categories
Headings options: options related to headings and the table of contents (or sidebar, depending on the theme used)
Members options: options related to filtering or ordering members in the generated documentation
Docstrings options: options related to docstrings (parsing and rendering)
Signature options: options related to signatures and type annotations
Pre-load modules that are not specified directly in autodoc instructions (::: identifier). It is useful when you want to render documentation for a particular member of an object, and this member is imported from another package than its parent.
For an imported member to be rendered, you need to add it to the __all__ attribute of the importing module.
The modules must be listed as an array of strings. Default: None.
A boolean, or an explicit list of inherited members to render. If true, select all inherited members, which can then be filtered with members. If false or empty list, do not select any inherited member. Default: False.
A boolean, or an explicit list of members to render. If true, select all members without further filtering. If false or empty list, do not render members. If none, select all members and apply further filtering with filters and docstrings. Default: None.
The members ordering to use. Options: alphabetical - order by the members names, source - order members as they appear in the source file. Default: "alphabetical".
A list of filters applied to filter objects based on their name. A filter starting with ! will exclude matching objects instead of including them. The members option takes precedence over filters (filters will still be applied recursively to lower members in the hierarchy). Default: ["!^_[^_]"].
There are multiple ways to tell the handler where to find your packages/modules.
The recommended method is to use the paths option, as it's the only one that works with the -f option of MkDocs, allowing to build the documentation from any location on the file system. Indeed, the paths provided with the paths option are computed as relative to the configuration file (mkdocs.yml), so that the current working directory has no impact on the build process: you can build the docs from any location on your filesystem.
These options affect how the documentation is collected from sources and rendered. See the following tables summarizing the options, and get more details for each option in the following pages:
General options: various options that do not fit in the other categories
Headings options: options related to headings and the table of contents (or sidebar, depending on the theme used)
Members options: options related to filtering or ordering members in the generated documentation
Docstrings options: options related to docstrings (parsing and rendering)
Signature options: options related to signatures and type annotations
Pre-load modules that are not specified directly in autodoc instructions (::: identifier). It is useful when you want to render documentation for a particular member of an object, and this member is imported from another package than its parent.
For an imported member to be rendered, you need to add it to the __all__ attribute of the importing module.
The modules must be listed as an array of strings. Default: None.
A boolean, or an explicit list of inherited members to render. If true, select all inherited members, which can then be filtered with members. If false or empty list, do not select any inherited member. Default: False.
A boolean, or an explicit list of members to render. If true, select all members without further filtering. If false or empty list, do not render members. If none, select all members and apply further filtering with filters and docstrings. Default: None.
The members ordering to use. Options: alphabetical - order by the members names, source - order members as they appear in the source file. Default: "alphabetical".
A list of filters applied to filter objects based on their name. A filter starting with ! will exclude matching objects instead of including them. The members option takes precedence over filters (filters will still be applied recursively to lower members in the hierarchy). Default: ["!^_[^_]"].
There are multiple ways to tell the handler where to find your packages/modules.
The recommended method is to use the paths option, as it's the only one that works with the -f option of MkDocs, allowing to build the documentation from any location on the file system. Indeed, the paths provided with the paths option are computed as relative to the configuration file (mkdocs.yml), so that the current working directory has no impact on the build process: you can build the docs from any location on your filesystem.
Except for case 1, which is supported by default, we strongly recommend setting the path to your packages using this option, even if it works without it (for example because your project manager automatically adds src to PYTHONPATH), to make sure anyone can build your docs from any location on their filesystem.
This method might work for you, with your current setup, but not for others trying your build your docs with their own setup/environment. We recommend using the paths method instead.
You can take advantage of the usual Python loading mechanisms. In Bash and other shells, you can run your command like this (note the prepended PYTHONPATH=...):