[](https://github.com/pyTooling/sphinx-reports)
[](LICENSE.md)
[](https://github.com/pyTooling/sphinx-reports/tags)
[](https://github.com/pyTooling/sphinx-reports/releases/latest)
[](https://github.com/pyTooling/sphinx-reports/releases)
[](https://github.com/pyTooling/sphinx-reports/actions?query=workflow%3A%22Test%2C+Coverage+and+Release%22)
[](https://pypi.org/project/sphinx-reports/)
[](https://github.com/pyTooling/sphinx-reports/network/dependents)
[](https://libraries.io/github/pyTooling/sphinx-reports)
[](https://requires.io/github/pyTooling/sphinx-reports/requirements/?branch=master)
[](https://www.codacy.com/manual/pyTooling/sphinx-reports)
[](https://www.codacy.com/manual/pyTooling/sphinx-reports)
[](https://codecov.io/gh/pyTooling/sphinx-reports)
[](https://libraries.io/github/pyTooling/sphinx-reports/sourcerank)
<!-- [](https://pyVersioning.readthedocs.io/en/latest/) -->
# Sphinx Reports
The Sphinx extension `sphinx_reports` offers a set of directives to integrate reports and summaries into the
documentation generated by Sphinx.
Supported format reports are:
* ✅ Documentation coverage (by [docstr_coverage](https://github.com/HunterMcGushion/docstr_coverage) (or `interrogate`?))
* 🚧 Code coverage (by [Coverage.py](https://github.com/nedbat/coveragepy))
* ✅ Summary page (displaying `coverage.json`)
* 🚧 Highlighted source code
* ✅🚧 Unit Test summaries (by [pytest](https://github.com/pytest-dev/pytest))
* ✅ Summary page (displaying `unittest.xml`)
* 🚧 Show logging, output and error messages.
* 🚧 Dependencies (reading `requirements.txt` files)
## Extension Configuration
This README demonstrates a quick and minimal configuration for the Sphinx extension and it's provided directives. See
the [sphinx-reports documentation](https://pyTooling.github.io/sphinx-reports) for more details.
At first, add the extension name to the list of extensions in `conf.py`, so the extension is loaded by Sphinx.
```Python
# Sphinx extensions
extensions = [
# ...
"sphinx_reports",
]
```
Each report directive might require an individual configuration, therefore see the next sections for details.
## Documentation Coverage
*Documentation Coverage* counts how many publicly accessible members are documented using a Python *doc-string*. Based
on the count of possibly documented public members and the actual number of non-empty *doc-strings*, a percentage of
documentation coverage can be computed.
Documentation coverage is a measure of code quality, which expresses how well documented (completeness or documentation,
but not necessarily quality/helpfulness of documentation) source code is. Well documented code helps to use and maintain
the existing code base. It also allows for automated documentation generation.
### Quick Configuration
This is a quick and minimal configuration for the *documentation coverage* directives.
See [documentation coverage](https://pyTooling.github.io/sphinx-reports/DocCov/index.html) documentation for more
details.
1. Configure one or more Python packages for documentation coverage analysis in `conf.py` by adding a new 'section'
defining some configuration variables. Each package is identified by an ID, which is later referred to by the report
directive. Here, the ID is called `src` (dictionary key). Each package needs 4 configuration entries:
* `name` - Name of the Python package[^1].
* `directory` - The directory of the package to analyze.
* `fail_below` - An integer value in range 0..100, for when a documentation coverage is considered FAILED.
* `levels` - A dictionary of coverage limits, their description and CSS style classes.
```Python
# ==============================================================================
# Sphinx-reports - DocCov
# ==============================================================================
report_doccov_packages = {
"src": {
"name": "myPackage",
"directory": "../myPackage",
"fail_below": 80,
"levels": {
30: {"class": "report-cov-below30", "desc": "almost undocumented"},
50: {"class": "report-cov-below50", "desc": "poorly documented"},
80: {"class": "report-cov-below80", "desc": "roughly documented"},
90: {"class": "report-cov-below90", "desc": "well documented"},
100: {"class": "report-cov-below100", "desc": "excellent documented"},
"error": {"class": "report-cov-error", "desc": "internal error"},
},
}
}
```
2. Add the `doc-coverage` directive into your Restructured Text (ReST) document.
* `packageid` - The ID used in `conf.py` to describe a Python package.
* `legend` (optional) - Position of the legend (`no_legend`, `top`, `bottom`, `both`)
```Python
.. report:doc-coverage::
:packageid: src
```
## Code Coverage
*Code Coverage* checks if a source code was used during execution. Usually, testcases are run by a testcase execution
framework like [pytest](https://github.com/pytest-dev/pytest), which also offers to instrument the code for code
coverage collection using the `pytest-cov` plugin. For Python, coverage collection is usually based on
[Coverage.py](https://github.com/nedbat/coveragepy>), which supports statement and branch coverage collection.
### Quick Configuration
This is a quick and minimal configuration for the *code coverage* directives.
See [code coverage](https://pyTooling.github.io/sphinx-reports/CodeCov/index.html) documentation for more
details.
1. Configure one or more coverage analysis reports in `conf.py` by adding a new 'section' defining some configuration
variables. Each analysis report is identified by an ID, which is later referred to by the report directive. Here, the
ID is called ``src`` (dictionary key). Each analysis report needs 4 configuration entries:
* `name` - Name of the Python package[^1].
* `json_report` - The code coverage report as JSON file as generated by *Coverage.py*.
* `fail_below` - An integer value in range 0..100, for when a code coverage is considered FAILED.
* `levels` - A dictionary of coverage limits, their description and CSS style classes.
```Python
# ==============================================================================
# Sphinx-reports - CodeCov
# ==============================================================================
report_codecov_packages = {
"src": {
"name": "myPackage",
"json_report": "../report/coverage/coverage.json",
"fail_below": 80,
"levels": {
30: {"class": "report-cov-below30", "desc": "almost unused"},
50: {"class": "report-cov-below50", "desc": "poorly used"},
80: {"class": "report-cov-below80", "desc": "medium used"},
90: {"class": "report-cov-below90", "desc": "well well"},
100: {"class": "report-cov-below100", "desc": "excellent used"},
"error": {"class": "report-cov-error", "desc": "internal error"},
},
}
}
```
2. Add the `code-coverage` directive into your Restructured Text (ReST) document.
* `packageid` - The ID used in `conf.py` to describe a Python package.
* `legend` (optional) - Position of the legend (`no_legend`, `top`, `bottom`, `both`)
```Python
.. report:code-coverage::
:packageid: src
```
## Unit Test Summary
```
UnitTest: write introduction
```
## Dependencies
```
Dep: write introduction
```
## Contributors
* [Patrick Lehmann](https://github.com/Paebbels) (Maintainer)
* [and more...](https://GitHub.com/pyTooling/sphinx-reports/graphs/contributors)
## License
This Python package (source code) is licensed under [Apache License 2.0](LICENSE.md).
The accompanying documentation is licensed under Creative Commons - Attribution-4.0 (CC-BY 4.0).
-------------------------
SPDX-License-Identifier: Apache-2.0
[^1]: Toplevel Python packages can reside in a directory not matching the package name. This is possible because the
toplevel package name is set in the package installation description. This is not good practice, but possible and
unfortunately widely used. E.g. `src` as directory name.
Raw data
{
"_id": null,
"home_page": "https://GitHub.com/pyTooling/sphinx_reports",
"name": "sphinx-reports",
"maintainer": null,
"docs_url": null,
"requires_python": ">=3.10",
"maintainer_email": null,
"keywords": "Python3, Sphinx, Extension, Report, doc-string, interrogate",
"author": "Patrick Lehmann",
"author_email": "Paebbels@gmail.com",
"download_url": "https://files.pythonhosted.org/packages/db/d0/f81cd2c7fe9ee810bd7276df4e45bedce6202f6914b0da21f52f7c2ace95/sphinx_reports-0.7.4.tar.gz",
"platform": null,
"description": "[](https://github.com/pyTooling/sphinx-reports)\n[](LICENSE.md)\n[](https://github.com/pyTooling/sphinx-reports/tags)\n[](https://github.com/pyTooling/sphinx-reports/releases/latest)\n[](https://github.com/pyTooling/sphinx-reports/releases) \n[](https://github.com/pyTooling/sphinx-reports/actions?query=workflow%3A%22Test%2C+Coverage+and+Release%22)\n[](https://pypi.org/project/sphinx-reports/)\n\n\n[](https://github.com/pyTooling/sphinx-reports/network/dependents) \n[](https://libraries.io/github/pyTooling/sphinx-reports)\n[](https://requires.io/github/pyTooling/sphinx-reports/requirements/?branch=master) \n[](https://www.codacy.com/manual/pyTooling/sphinx-reports)\n[](https://www.codacy.com/manual/pyTooling/sphinx-reports)\n[](https://codecov.io/gh/pyTooling/sphinx-reports)\n[](https://libraries.io/github/pyTooling/sphinx-reports/sourcerank) \n<!-- [](https://pyVersioning.readthedocs.io/en/latest/) -->\n\n\n# Sphinx Reports\n\nThe Sphinx extension `sphinx_reports` offers a set of directives to integrate reports and summaries into the\ndocumentation generated by Sphinx.\n\nSupported format reports are:\n* \u2705 Documentation coverage (by [docstr_coverage](https://github.com/HunterMcGushion/docstr_coverage) (or `interrogate`?))\n* \ud83d\udea7 Code coverage (by [Coverage.py](https://github.com/nedbat/coveragepy))\n * \u2705 Summary page (displaying `coverage.json`)\n * \ud83d\udea7 Highlighted source code\n* \u2705\ud83d\udea7 Unit Test summaries (by [pytest](https://github.com/pytest-dev/pytest))\n * \u2705 Summary page (displaying `unittest.xml`)\n * \ud83d\udea7 Show logging, output and error messages.\n* \ud83d\udea7 Dependencies (reading `requirements.txt` files)\n\n\n\n\n## Extension Configuration\n\nThis README demonstrates a quick and minimal configuration for the Sphinx extension and it's provided directives. See\nthe [sphinx-reports documentation](https://pyTooling.github.io/sphinx-reports) for more details.\n\nAt first, add the extension name to the list of extensions in `conf.py`, so the extension is loaded by Sphinx.\n\n```Python\n# Sphinx extensions\nextensions = [\n # ...\n \"sphinx_reports\",\n]\n```\n\nEach report directive might require an individual configuration, therefore see the next sections for details.\n\n## Documentation Coverage\n\n*Documentation Coverage* counts how many publicly accessible members are documented using a Python *doc-string*. Based\non the count of possibly documented public members and the actual number of non-empty *doc-strings*, a percentage of\ndocumentation coverage can be computed.\n\nDocumentation coverage is a measure of code quality, which expresses how well documented (completeness or documentation,\nbut not necessarily quality/helpfulness of documentation) source code is. Well documented code helps to use and maintain\nthe existing code base. It also allows for automated documentation generation.\n\n\n### Quick Configuration\n\nThis is a quick and minimal configuration for the *documentation coverage* directives.\nSee [documentation coverage](https://pyTooling.github.io/sphinx-reports/DocCov/index.html) documentation for more\ndetails.\n\n1. Configure one or more Python packages for documentation coverage analysis in `conf.py` by adding a new 'section' \n defining some configuration variables. Each package is identified by an ID, which is later referred to by the report\n directive. Here, the ID is called `src` (dictionary key). Each package needs 4 configuration entries:\n\n * `name` - Name of the Python package[^1].\n * `directory` - The directory of the package to analyze.\n * `fail_below` - An integer value in range 0..100, for when a documentation coverage is considered FAILED.\n * `levels` - A dictionary of coverage limits, their description and CSS style classes.\n\n ```Python\n # ==============================================================================\n # Sphinx-reports - DocCov\n # ==============================================================================\n report_doccov_packages = {\n \"src\": {\n \"name\": \"myPackage\",\n \"directory\": \"../myPackage\",\n \"fail_below\": 80,\n \"levels\": {\n 30: {\"class\": \"report-cov-below30\", \"desc\": \"almost undocumented\"},\n 50: {\"class\": \"report-cov-below50\", \"desc\": \"poorly documented\"},\n 80: {\"class\": \"report-cov-below80\", \"desc\": \"roughly documented\"},\n 90: {\"class\": \"report-cov-below90\", \"desc\": \"well documented\"},\n 100: {\"class\": \"report-cov-below100\", \"desc\": \"excellent documented\"},\n \"error\": {\"class\": \"report-cov-error\", \"desc\": \"internal error\"},\n },\n }\n }\n ```\n2. Add the `doc-coverage` directive into your Restructured Text (ReST) document.\n \n * `packageid` - The ID used in `conf.py` to describe a Python package.\n * `legend` (optional) - Position of the legend (`no_legend`, `top`, `bottom`, `both`)\n\n ```Python\n .. report:doc-coverage::\n :packageid: src\n ```\n\n## Code Coverage\n\n*Code Coverage* checks if a source code was used during execution. Usually, testcases are run by a testcase execution\nframework like [pytest](https://github.com/pytest-dev/pytest), which also offers to instrument the code for code\ncoverage collection using the `pytest-cov` plugin. For Python, coverage collection is usually based on\n[Coverage.py](https://github.com/nedbat/coveragepy>), which supports statement and branch coverage collection.\n\n### Quick Configuration\n\nThis is a quick and minimal configuration for the *code coverage* directives.\nSee [code coverage](https://pyTooling.github.io/sphinx-reports/CodeCov/index.html) documentation for more\ndetails.\n\n1. Configure one or more coverage analysis reports in `conf.py` by adding a new 'section' defining some configuration\n variables. Each analysis report is identified by an ID, which is later referred to by the report directive. Here, the\n ID is called ``src`` (dictionary key). Each analysis report needs 4 configuration entries:\n\n * `name` - Name of the Python package[^1].\n * `json_report` - The code coverage report as JSON file as generated by *Coverage.py*.\n * `fail_below` - An integer value in range 0..100, for when a code coverage is considered FAILED.\n * `levels` - A dictionary of coverage limits, their description and CSS style classes.\n\n ```Python\n # ==============================================================================\n # Sphinx-reports - CodeCov\n # ==============================================================================\n report_codecov_packages = {\n \"src\": {\n \"name\": \"myPackage\",\n \"json_report\": \"../report/coverage/coverage.json\",\n \"fail_below\": 80,\n \"levels\": {\n 30: {\"class\": \"report-cov-below30\", \"desc\": \"almost unused\"},\n 50: {\"class\": \"report-cov-below50\", \"desc\": \"poorly used\"},\n 80: {\"class\": \"report-cov-below80\", \"desc\": \"medium used\"},\n 90: {\"class\": \"report-cov-below90\", \"desc\": \"well well\"},\n 100: {\"class\": \"report-cov-below100\", \"desc\": \"excellent used\"},\n \"error\": {\"class\": \"report-cov-error\", \"desc\": \"internal error\"},\n },\n }\n }\n ```\n2. Add the `code-coverage` directive into your Restructured Text (ReST) document.\n \n * `packageid` - The ID used in `conf.py` to describe a Python package.\n * `legend` (optional) - Position of the legend (`no_legend`, `top`, `bottom`, `both`)\n\n ```Python\n .. report:code-coverage::\n :packageid: src\n ```\n\n## Unit Test Summary\n\n```\nUnitTest: write introduction\n```\n\n\n## Dependencies\n\n```\nDep: write introduction\n```\n\n\n## Contributors\n\n* [Patrick Lehmann](https://github.com/Paebbels) (Maintainer)\n* [and more...](https://GitHub.com/pyTooling/sphinx-reports/graphs/contributors)\n\n\n## License\n\nThis Python package (source code) is licensed under [Apache License 2.0](LICENSE.md). \nThe accompanying documentation is licensed under Creative Commons - Attribution-4.0 (CC-BY 4.0).\n\n\n-------------------------\n\nSPDX-License-Identifier: Apache-2.0\n\n\n[^1]: Toplevel Python packages can reside in a directory not matching the package name. This is possible because the\n toplevel package name is set in the package installation description. This is not good practice, but possible and\n unfortunately widely used. E.g. `src` as directory name.\n",
"bugtrack_url": null,
"license": "Apache-2.0",
"summary": "A Sphinx extension providing reports and summaries embedded in documentation pages.",
"version": "0.7.4",
"project_urls": {
"Documentation": "https://pyTooling.GitHub.io/sphinx_reports",
"Homepage": "https://GitHub.com/pyTooling/sphinx_reports",
"Issue Tracker": "https://GitHub.com/pyTooling/sphinx_reports/issues",
"Source Code": "https://GitHub.com/pyTooling/sphinx_reports"
},
"split_keywords": [
"python3",
" sphinx",
" extension",
" report",
" doc-string",
" interrogate"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "a2f33de7d4c6867733777e15c725c0406414d72ad820525d7b830b93ef35bff7",
"md5": "cf014f91b18638e23101223c345e9768",
"sha256": "b531d7e1c7e3f16c071d74557a780977b939e2e8f20aef518171d1edc6bc193b"
},
"downloads": -1,
"filename": "sphinx_reports-0.7.4-py3-none-any.whl",
"has_sig": false,
"md5_digest": "cf014f91b18638e23101223c345e9768",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.10",
"size": 40181,
"upload_time": "2024-11-03T19:47:04",
"upload_time_iso_8601": "2024-11-03T19:47:04.954206Z",
"url": "https://files.pythonhosted.org/packages/a2/f3/3de7d4c6867733777e15c725c0406414d72ad820525d7b830b93ef35bff7/sphinx_reports-0.7.4-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "dbd0f81cd2c7fe9ee810bd7276df4e45bedce6202f6914b0da21f52f7c2ace95",
"md5": "f571e31779536879fb0f9d12ca435b1b",
"sha256": "2875b00417410fffb0a914d717b5a76e4b36bde8472ea8fce1492e653b535adb"
},
"downloads": -1,
"filename": "sphinx_reports-0.7.4.tar.gz",
"has_sig": false,
"md5_digest": "f571e31779536879fb0f9d12ca435b1b",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.10",
"size": 31496,
"upload_time": "2024-11-03T19:47:03",
"upload_time_iso_8601": "2024-11-03T19:47:03.330331Z",
"url": "https://files.pythonhosted.org/packages/db/d0/f81cd2c7fe9ee810bd7276df4e45bedce6202f6914b0da21f52f7c2ace95/sphinx_reports-0.7.4.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-11-03 19:47:03",
"github": false,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"lcname": "sphinx-reports"
}
JSON