Fix Sphinx roles in README that fail twine check (and gate it in PR CI)#78
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The v0.4.0 release failed at the PyPI publish step because the README I added in #77 used Sphinx interpreted-text roles (
:class:\pyvista.PolyData`,:class:`pyacvd.Clustering`) whichtwine check` rejects. Failure: https://github.com/pyvista/pyacvd/actions/runs/25574339938/job/75079011573PyPI's RST renderer is plain docutils and doesn't know about Sphinx roles, so the
long_descriptionfails markup validation and the upload aborts. My mistake.Fix
Replace the two
:class:\...`references with plain``...``` literals. The accessor docstrings still use proper Sphinx roles since they're rendered by the API docs build, not by PyPI.Prevent recurrence
Add
twine check --strict dist/*.tar.gzto thebuild_sdistjob in.github/workflows/build-and-deploy.ymlso every PR exercises the same check the release job runs.--stricttreats warnings as errors. The release path itself was already guarded; the gap was that PRs never built the sdist's metadata in a way that surfaced the failure before tagging.Verification
Built the sdist locally and ran
twine check --strictagainst it: passes. After this PR merges, the v0.4.0 release will need to be retagged (e.g. v0.4.1) so the publish step runs against the corrected sdist.