v0.11.2 by Paebbels · Pull Request #99 · pyTooling/sphinx-reports

Paebbels · 2026-07-31T15:17:22Z

Bug Fixes

sphinx_reports could not be imported alongside pyTooling 8.18.0. Any documentation build using this extension failed at import:
```
File ".../sphinx_reports/DataModel/CodeCoverage.py", line 51
  from pyEDAA.Reports.DocumentationCoverage.Python import PackageCoverage
File ".../pyEDAA/Reports/DocumentationCoverage/Python.py"
  class DocStrCoverage(metaclass=ExtendedType):
  	del ResultCollection
...
  _coverageReport:  ResultCollection
NameError: name 'ResultCollection' is not defined
```
pyEDAA.Reports 0.17.4 imports ResultCollection inside the class body and dels the name at the end of it. Under PEP 649 the annotation is evaluated lazily, by which time the name is gone. It stayed asleep because pyTooling 8.17.0's non-slots branch of _computeSlots read only members["__annotations__"], which Python 3.14 doesn't provide — so the annotation was never evaluated. v8.18.0 added the PEP 649 fallback to that branch, which is correct (it was collecting no class fields at all), and the latent defect started raising.

pyEDAA.Reports 0.18.0 moved both imports to module level and dropped the del, so widening the pin is the whole fix.

Worth stating explicitly, because it is the natural first guess: this is not a missing dependency. docstr_coverage ~= 2.3.2 is a direct requirement of this package and was installed all along — a missing package raises ModuleNotFoundError at the import statement, not NameError at annotation evaluation.

Changes

pyEDAA.Reports ~= 0.17.4 → ~= 0.18. Note this transitively raises the pyTooling floor, since pyEDAA.Reports 0.18.0 requires pyTooling[terminal] >= 8.18.

Dependencies bumped, applying the five open dependabot proposals by hand:

Dependency	From	To	Dependabot PR
pyTooling	`>= 8.16` / `~= 8.16`	`>= 8.19` / `~= 8.19`	[Dependabot]: Update pytooling requirement from ~=8.16 to ~=8.17 #97
sphinxcontrib-mermaid	`~= 2.0`	`~= 2.1`	[Dependabot]: Update sphinxcontrib-mermaid requirement from ~=2.0 to ~=2.1 #96
sphinx_autodoc_typehints	`~= 3.12`	`~= 3.13`	[Dependabot]: Update sphinx-autodoc-typehints requirement from ~=3.12 to ~=3.13 #98
lxml	`>= 6.1`	`>= 6.1.1`	[Dependabot]: Update lxml requirement from <7.0,>=6.1 to >=6.1.1,<7.0 #91

pyTooling goes to 8.19, not the 8.17 dependabot proposed — 8.17 was latest when that PR opened, 8.19.0 is current, and pyEDAA.Reports ~= 0.18 already forces >= 8.18 transitively.

docutils was not bumped. Dependabot's [Dependabot]: Update docutils requirement from >=0.22.0 to >=0.23 #89 (>= 0.22.0 → >= 0.23) is unmergeable: sphinx >= 9.1, < 10.0 caps it, since sphinx 9.1.0 requires docutils<0.23,>=0.21. Applying it made pip resolution fail in every job that installs requirements.txt, so it is reverted and stays at >= 0.22.0 until Sphinx relaxes that bound.

They were applied by hand rather than merged for two reasons. Dependabot only edits requirement files, so each merge would have left the matching doc/Dependency.rst row stale. And [Dependabot]: Update lxml requirement from <7.0,>=6.1 to >=6.1.1,<7.0 #91 and [Dependabot]: Update docutils requirement from >=0.22.0 to >=0.23 #89 were branched before the v0.11.1 release, so merging either would have reset __version__ and $PackageVersion to 0.11.1 — [Dependabot]: Update lxml requirement from <7.0,>=6.1 to >=6.1.1,<7.0 #91 would additionally have dropped the __project_url__ / __documentation_url__ / __issue_tracker_url__ dunder variables added since.

Bumped mypy[reports] to ~= 2.3 (in 2bd09a8, before this change).

Documentation

doc/Dependency.rst gains a pyEDAA.Reports row in the mandatory-dependency table, so it moves out of the .. TODO:: document the dependency to list.
Six dependency rows in doc/Dependency.rst updated to match the bumps above. Nothing keeps that file in step with the requirement files, so it had drifted: two of the three pyTooling rows still read ≥8.11, three releases behind what requirements.txt said.

Unit Tests

Unchanged — pytest tests/unit: 2 passed. The defect was an import-time failure in a dependency, which the suite reaches only if the import succeeds.

Verification

Against pyTooling 8.18+:

Scenario	Result
`sphinx_reports` + pyEDAA.Reports v0.17.4 (the old pin)	`NameError: name 'ResultCollection' is not defined` — reproduces CI exactly
`sphinx_reports` + pyEDAA.Reports 0.18	`sphinx_reports.DataModel.CodeCoverage` imports cleanly
`pytest tests/unit`	2 passed
`doc/Dependency.rst` grid tables	6 tables, 0 with mixed row widths; all six dependency tables re-parse under docutils with 0 errors
`pip install --dry-run` on `requirements.txt`, `doc/requirements.txt`, `tests/typing/requirements.txt`	all resolve

Version bumped in sphinx_reports/__init__.py and run.ps1.

Related Issues and Pull-Requests

Downstream: this unblocks the HTML documentation job of VHDL/pyVHDLModel#167 (v0.38.0), which is the build that surfaced the problem.
Upstream fix: edaa-org/pyEDAA.Reports#153, released in pyEDAA.Reports v0.18.0.
Supersedes and closes the dependabot PRs [Dependabot]: Update lxml requirement from <7.0,>=6.1 to >=6.1.1,<7.0 #91, [Dependabot]: Update sphinxcontrib-mermaid requirement from ~=2.0 to ~=2.1 #96, [Dependabot]: Update pytooling requirement from ~=8.16 to ~=8.17 #97 and [Dependabot]: Update sphinx-autodoc-typehints requirement from ~=3.12 to ~=3.13 #98.
[Dependabot]: Update docutils requirement from >=0.22.0 to >=0.23 #89 (docutils) is closed as not applicable rather than applied — see the note under Changes.

`pyEDAA.Reports ~= 0.17.4` excludes 0.18, and 0.17.4 cannot be imported alongside pyTooling 8.18.0: File ".../pyEDAA/Reports/DocumentationCoverage/Python.py" class DocStrCoverage(metaclass=ExtendedType): del ResultCollection ... _coverageReport: ResultCollection NameError: name 'ResultCollection' is not defined 0.17.4 imports `ResultCollection` inside the class body and deletes the name at the end of it. Under PEP 649 the annotation is evaluated lazily, by which time the name is gone. It stayed asleep because pyTooling 8.17.0's non-slots branch of `_computeSlots` read only `members["__annotations__"]`, which Python 3.14 doesn't provide, so the annotation was never evaluated. v8.18.0 added the PEP 649 fallback to that branch and the latent defect started raising. pyEDAA.Reports 0.18.0 moved both imports to module level and dropped the `del`, so widening the pin is the whole fix. This is not about a missing dependency - `docstr_coverage ~= 2.3.2` is a direct requirement here and was installed all along; a missing package would raise `ModuleNotFoundError` at the import, not `NameError` at annotation evaluation. Verified against pyTooling 8.18+: * pyEDAA.Reports v0.17.4 -> NameError, as in CI * pyEDAA.Reports 0.18 -> `sphinx_reports.DataModel.CodeCoverage` imports * `pytest tests/unit` -> 2 passed `doc/Dependency.rst` gains a pyEDAA.Reports row in the mandatory-dependency table, so it moves out of the "document the dependency to" TODO. The pyTooling row's floor there was stale at >=8.11 while `requirements.txt` already said >=8.16; corrected. Grid column widths are preserved and the table re-parses under docutils with 0 errors. Co-Authored-By: Patrick Lehmann <Paebbels@gmail.com>

codacy-production · 2026-07-31T15:18:45Z

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric Results

Complexity 0

Duplication 0

View in Codacy

🟢 Coverage 100.00% diff coverage · +0.00% coverage variation

Metric Results

Coverage variation ✅ +0.00% coverage variation (-1.00%)

Diff coverage ✅ 100.00% diff coverage

View coverage diff in Codacy

Coverage variation details

Coverable lines Covered lines Coverage

Common ancestor commit (bd8a183) Report Missing Report Missing Report Missing

Head commit (96985c3) 1371 (+0) 495 (+0) 36.11% (+0.00%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

Coverable lines Covered lines Diff coverage

Pull request (#99) 1 1 100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

¹ Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct.

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer}
_{TIP This summary will be updated as you push new changes.}

Applies the five open dependabot proposals by hand, because merging them would leave `doc/Dependency.rst` untouched - dependabot only edits requirement files - and two of them would have reverted the version bump. | Dependency | From | To | Was | |---|---|---|---| | pyTooling | >= 8.16 / ~= 8.16 | >= 8.19 / ~= 8.19 | #97 | | docutils | >= 0.22.0 | >= 0.23 | #89 | | sphinxcontrib-mermaid | ~= 2.0 | ~= 2.1 | #96 | | sphinx_autodoc_typehints | ~= 3.12 | ~= 3.13 | #98 | | lxml | >= 6.1 | >= 6.1.1 | #91 | pyTooling goes to 8.19, not the 8.17 dependabot proposed: 8.17 was the latest when that PR opened, 8.19.0 is current, and `pyEDAA.Reports ~= 0.18` already forces `>= 8.18` transitively. Tracking latest matches what 2bd09a8 did. #91 and #89 were branched before the v0.11.1 release, so merging either would have reset `__version__` and `$PackageVersion` to 0.11.1 - and #91 would also have dropped the `__project_url__`/`__documentation_url__`/`__issue_tracker_url__` dunder variables added since. Six rows in `doc/Dependency.rst` updated to match. Two of the three pyTooling rows still read >=8.11, stale by three releases, since nothing keeps that file in step with the requirement files. Column widths are preserved; all six dependency tables re-parse under docutils with 0 errors. `pytest tests/unit`: 2 passed. Co-Authored-By: Patrick Lehmann <Paebbels@gmail.com>

`docutils >= 0.23` is unsatisfiable alongside `sphinx >= 9.1, < 10.0`: The user requested docutils>=0.23 sphinx 9.1.0 depends on docutils<0.23 and >=0.21 ERROR: ResolutionImpossible Every job that installs `requirements.txt` failed at pip resolution - 29 of them, including all unit tests, all install jobs and both documentation jobs. The previous commit was 39/39 green, so this was entirely my change. Dependabot's proposal (#89) was unmergeable for the same reason; merging it would have broken the pipeline identically. It can only be applied once Sphinx relaxes its upper bound. Back to `>= 0.22.0`. The other four bumps are unaffected - `pip install --dry-run` now resolves `requirements.txt`, `doc/requirements.txt` and `tests/typing/requirements.txt` cleanly, and `pytest tests/unit` passes (2 passed). No `doc/Dependency.rst` change: docutils has no row in that file. Co-Authored-By: Patrick Lehmann <Paebbels@gmail.com>

codecov · 2026-07-31T15:48:05Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 35.88%. Comparing base (bd8a183) to head (96985c3).
⚠️ Report is 10 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #99   +/-   ##
=======================================
  Coverage   35.88%   35.88%           
=======================================
  Files          15       15           
  Lines        1371     1371           
  Branches      154      154           
=======================================
  Hits          492      492           
  Misses        876      876           
  Partials        3        3

Flag	Coverage Δ
unittests	`35.88% <100.00%> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [pyTooling/Actions](https://redirect.github.com/pyTooling/Actions) | action | minor | `v7.13.1` → `v7.14.1` | --- ### Release Notes <details> <summary>pyTooling/Actions (pyTooling/Actions)</summary> ### [`v7.14.1`](https://redirect.github.com/pyTooling/Actions/releases/tag/v7.14.1) [Compare Source](https://redirect.github.com/pyTooling/Actions/compare/v7.14.0...v7.14.1) ### Changes - **`PrepareJob.yml` associates the Pull Request exactly instead of taking the first search hit.** `gh pr list --search <sha>` lists every merged Pull Request that *contains* that commit, so it can return more than one — an older release Pull Request built from an ancestor matches just as well — and the code then took `.[0]` of an unordered list. The second parent (*father*) of a merge commit **is** the head commit of the merged branch, so the candidates are now reduced to those whose `headRefOid` equals it: If a Pull Request was closed and recreated from the same branch — rare, but possible — both share a head commit, and the most recently merged one is used, with a warning naming both. Everything stays derived from the commit graph. ### Bug Fixes - **`PrepareJob.yml`: `Prepare` failed for every merge commit on the development branch.** The step *Find merged PullRequest from second parent* searches a **merged Pull Request whose base is the release branch**, but it was guarded by `is_merge_commit` alone. A merge commit pushed to the development branch originates from a Pull Request based on the *development* branch, so the search can never match and the step exits 1 — taking the whole `Prepare` job, and with it the run, down. Downstream effect: on a development-branch merge, `Prepare.outputs.version` is now empty, as it already was for regular commits. `VersionCheck` is guarded by `needs.Prepare.outputs.version != ''` and is therefore correctly **skipped** there — it only ever ran on such pushes by way of the match above. On the release path nothing changes. - **`PrepareJob.yml`: a search without a hit was not detected.** `gh pr list --json …` returns an empty JSON **array**, not an empty string, so `[[ "${PULL_REQUESTS}" == "" ]]` never triggered. A no-match fell through to `jq .[0].title` → the literal `null`, and only the later regexp check reported it — as a confusing complaint about a title named `null`. No match is now an error that lists the candidates the search did return. - **`CleanupArtifacts.yml`: the second delete step deleted the first set again.** The step guarded itself with `steps.compute2` but passed the names resolved by `steps.compute`: ### Documentation - `doc/JobTemplate/Setup/PrepareJob.rst` — the *Behavior* topic now states that step 4 runs for release commits only, and how the pull-request is identified (`headRefOid` equal to the second parent, newest wins on a tie). *** ### Related Issues and Pull-Requests - [#242](https://redirect.github.com/pyTooling/Actions/issues/242) ### [`v7.14.0`](https://redirect.github.com/pyTooling/Actions/releases/tag/v7.14.0) [Compare Source](https://redirect.github.com/pyTooling/Actions/compare/v7.13.1...v7.14.0) ### New Features - **`CleanupArtifacts.yml` gained `condition` and `condition2`.** Two boolean inputs, defaulting to `true`, placed between each JSON dictionary and its id list: | | | | ------------------------------------------------- | ---------- | | `json` → **`condition`** → `artifact-json-ids` | first set | | `json2` → **`condition2`** → `artifact-json-ids2` | second set | Each is wired into the `if:` of both its *compute* and its *delete* step, so a disabled set neither resolves names nor deletes anything. Existing callers are unaffected — the default preserves today's behaviour. ### Bug Fixes - **The package artifact could be deleted while `PublishOnPyPI` was using it.** In `CompletePipeline.yml`, `ArtifactCleanUp` listed `package_all` in the unconditional set, while its `needs:` has `# - PublishOnPyPI` commented out — so on a release-tag run the cleanup and the upload ran **concurrently**, and the wheel could vanish from under the publish job. `package_all` now moves to the guarded second set: ```yaml condition2: ${{ ! startsWith(github.ref, 'refs/tags') }} artifact-json-ids2: >- package_all ``` which is the same guard `ArtifactCleanUp.yml` has always had. On a tagged run `PublishOnPyPI` consumes the artifact and deletes it itself. The window is real and measured — pyTooling v8.19.0 ([run 30612877620](https://redirect.github.com/pyTooling/pyTooling/actions/runs/30612877620)): cleanup ran `07:34:28`→`07:34:40`, publish started `07:34:58`. That release survived only because `pyTooling/pyTooling` doesn't use `CompletePipeline.yml`; it calls the older `ArtifactCleanUp.yml`, whose guard kept `pyTooling-Packages` out of the deleted list. - **`VersionCheck` rejected every prefixed tag.** `Prepare.outputs.version` is derived from the tag and may carry a `v`/`r` prefix, while `extractVersionInformation(...).Version` is a plain `str` that never does — so the string comparison could never succeed for a repository tagging `vX.Y.Z`: ``` expected: v0.38.0 from code: 0.38.0 ##[error]Expected version (v0.38.0) doesn't match the version in Python code (0.38.0). ``` Hit by [VHDL/pyVHDLModel v0.38.0](https://redirect.github.com/VHDL/pyVHDLModel/actions/runs/30612778347) and [pyTooling/sphinx-reports v0.11.2](https://redirect.github.com/pyTooling/sphinx-reports/actions/runs/30644591170), and not workaroundable by a consumer. Both sides are now parsed with `SemanticVersion`, which ignores the prefix; a parse failure is reported as an error instead of crashing the step. ### Changes - **`ArtifactCleanUp.yml` now emits a deprecation warning.** A `::warning` annotation plus a migration note in the job log: `package` → `json2` + `artifact-json-ids2` guarded by `condition2`; `remaining` → `json` + `artifact-json-ids`, or `others` for literal names. Slated for removal in **r8**. The message deliberately avoids literal `${{ }}` braces — Actions substitutes those inside `run:` blocks before the shell sees them, so an example containing them would be evaluated rather than printed. ### Unit Tests - `_Checking_CleanupArtifacts.yml` moves `package_all` into the guarded second set, exercising `condition2`. - `_Checking_JobTemplates.yml` already binds both sets to two *different* name dictionaries (`UnitTestingParams` and `PlatformTestingParams`), so there was no free slot. The package artifact gets its own `PackageArtifactCleanUp` job using `condition`, which exercises the first-set guard **and** removes the same race from that pipeline — it has a `PublishOnPyPI` job too. ### Verification Version comparison, checked on pyTooling **8.17.0 and 8.19.0** — both the cases that must pass and the cases that must still fail: | expected (from tag) | in code | equal | wanted | | ------------------- | -------- | ----- | ------ | | `v0.11.2` | `0.11.2` | ✔ | ✔ | | `v0.38.0` | `0.38.0` | ✔ | ✔ | | `v8.19.0` | `8.19.0` | ✔ | ✔ | | `r7.13.1` | `7.13.1` | ✔ | ✔ | | `0.11.2` | `0.11.2` | ✔ | ✔ | | `v0.11.2` | `0.11.1` | ✘ | ✘ | | `v1.0.0` | `0.11.2` | ✘ | ✘ | All five changed workflows parse as YAML with balanced `${{ }}` expressions, and the deprecation script was executed to confirm its rendered output. *** ### Related Issues and Pull-Requests - Also in this release: [#238](https://redirect.github.com/pyTooling/Actions/issues/238) — application testing in the job template verification, reduced matrices. - Downstream reports: the `VersionCheck` failure blocked [VHDL/pyVHDLModel#167](https://redirect.github.com/VHDL/pyVHDLModel/pull/167) (v0.38.0) and [pyTooling/sphinx-reports#99](https://redirect.github.com/pyTooling/sphinx-reports/pull/99) (v0.11.2). > \[!NOTE] > The documentation is **not** updated in this release. `CleanupArtifacts.yml` has no documentation page at all — the documented `ArtifactCleanup.rst` covers the deprecated workflow — and the instantiation examples are still on `@r6`. Tracked separately; it needs a rework rather than a patch. </details> --- ### Configuration 📅 **Schedule**: (in timezone America/New_York) - Branch creation - "after 10am and before 4pm" - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/nsheaps/homebrew-devsetup).  Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Paebbels and others added 2 commits July 13, 2026 19:53

Bumped dependencies.

2bd09a8

Paebbels added Bug Something isn't working Dependencies Documentation Improvements or additions to documentation labels Jul 31, 2026

claude-code and others added 2 commits July 31, 2026 15:39

Paebbels self-assigned this Jul 31, 2026

Paebbels merged commit 84162b6 into main Jul 31, 2026
53 checks passed

This was referenced Jul 31, 2026

v7.14.0 pyTooling/Actions#240

Merged

Updating r7 from 7.14.0 pyTooling/Actions#241

Merged

Paebbels had a problem deploying to github-pages August 3, 2026 23:58 — with GitHub Actions Failure

Navigation Menu

Uh oh!

v0.11.2 - #99

v0.11.2#99
Paebbels merged 4 commits into
mainfrom
dev

Paebbels commented Jul 31, 2026 •

edited

Loading

Uh oh!

codacy-production Bot commented Jul 31, 2026 •

edited

Loading

Uh oh!

codecov Bot commented Jul 31, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Paebbels commented Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Bug Fixes

Changes

Documentation

Unit Tests

Verification

Related Issues and Pull-Requests

Uh oh!

codacy-production Bot commented Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Up to standards ✅

Uh oh!

codecov Bot commented Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Paebbels commented Jul 31, 2026 •

edited

Loading

codacy-production Bot commented Jul 31, 2026 •

edited

Loading

codecov Bot commented Jul 31, 2026 •

edited

Loading