Conversation
📝 WalkthroughWalkthroughUpdated CI and Dependabot: Dependabot GitHub Actions update schedule moved to weekly; workflows replaced setup-python with astral-sh/setup-uv (activate-environment, matrix python-version), added uvx twine check in release flow, updated Codecov to v5, and added a versioningit format in pyproject.toml. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release-pypi.yml:
- Line 63: The "Publish package to TestPyPI" job/step contains a constant
disabled condition `if: false` which triggers actionlint [if-cond]; remove the
entire "Publish package to TestPyPI" step block (the step titled "Publish
package to TestPyPI") or replace the `if: false` with a real runtime condition
such as checking a workflow input (e.g., a `workflow_dispatch` boolean input) or
an environment/branch check so the step uses a valid conditional instead of a
constant false.
ℹ️ Review info
Configuration used: Repository UI (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.github/dependabot.yml.github/workflows/release-pypi.yml.github/workflows/tests.yml
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@pyproject.toml`:
- Around line 240-242: The versioningit config only sets distance and relies on
defaults for dirty and distance-dirty (which include local '+' segments);
explicitly add entries under [tool.versioningit.format] for dirty and
distance-dirty to use PEP 440-compatible post-release segments (no '+' local
version), e.g. set dirty to a post-style format like "{base_version}.post0" and
distance-dirty to a post-style format using the distance like
"{base_version}.post{distance}" so all three keys (distance, dirty,
distance-dirty) are defined without local-version suffixes.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Run ID: a866f469-bb99-4373-b637-c0348ed17085
📒 Files selected for processing (2)
.github/workflows/release-pypi.ymlpyproject.toml
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/release-pypi.yml
| [tool.versioningit.format] | ||
| distance = "{base_version}.post{distance}" | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
versioningit format defaults dirty distance-dirty documentation
💡 Result:
In versioningit, the format step uses different templates depending on the repository “state”:
distance: there are commits since the most recent tagdirty: no commits since the most recent tag, but there are uncommitted changesdistance-dirty: there are commits since the most recent tag and there are uncommitted changes [1]
Default format templates
The documented default configuration is: [1]
[tool.versioningit.format]
distance = "{base_version}.post{distance}+{vcs}{rev}"
dirty = "{base_version}+d{build_date:%Y%m%d}"
distance-dirty = "{base_version}.post{distance}+{vcs}{rev}.d{build_date:%Y%m%d}"Notes:
{base_version}is the version taken from the most recent tag. (Older docs/examples may show{version}; it was renamed to{base_version}in v2.0.0, with{version}kept as a deprecated alias.) [1]{distance}= number of commits since the most recent tag;{rev}= abbreviated commit hash;{vcs}= first letter of VCS name (e.g.,gfor git);{build_date}is the build time (orSOURCE_DATE_EPOCHif set). [1]
Sources:
[1] versioningit “Configuration” docs (stable): default [tool.versioningit.format] values, state meanings, and available fields. (versioningit.readthedocs.io)
Citations:
🌐 Web query:
PyPI accepts local version segment PEP 440
💡 Result:
PEP 440 allows local version identifiers (the +local segment), e.g. 1.2.3+acme.1, mainly for downstream/private rebuilds. However, PyPI does not accept uploads that use a local version identifier: PEP 440 explicitly states that because PyPI is intended for upstream releases, it “MUST NOT allow the use of local version identifiers.” [1]
So, if you try to upload a distribution with a +... local segment in Version, PyPI/TestPyPI should reject it; use a public PEP 440 version (e.g. .postN, .devN, or pre-releases) for public publishing, and reserve +local for private indexes/internal builds. [1]
Sources:
[1] PEP 440 – “Local version identifiers” section (PyPI MUST NOT allow local versions): https://peps.python.org/pep-0440/
Configure dirty and distance-dirty explicitly to avoid PyPI-incompatible local version suffixes.
The current configuration specifies only distance, but versioningit defaults for unspecified states (dirty and distance-dirty) both include local version segments (+...). PyPI explicitly rejects any upload with a local version identifier per PEP 440. Since the PR goal is PyPI-compatible dirty versions, you must explicitly configure all three states without local segments.
Suggested config update
[tool.versioningit.format]
distance = "{base_version}.post{distance}"
+dirty = "{base_version}"
+distance-dirty = "{base_version}.post{distance}"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| [tool.versioningit.format] | |
| distance = "{base_version}.post{distance}" | |
| [tool.versioningit.format] | |
| distance = "{base_version}.post{distance}" | |
| dirty = "{base_version}" | |
| distance-dirty = "{base_version}.post{distance}" | |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@pyproject.toml` around lines 240 - 242, The versioningit config only sets
distance and relies on defaults for dirty and distance-dirty (which include
local '+' segments); explicitly add entries under [tool.versioningit.format] for
dirty and distance-dirty to use PEP 440-compatible post-release segments (no '+'
local version), e.g. set dirty to a post-style format like
"{base_version}.post0" and distance-dirty to a post-style format using the
distance like "{base_version}.post{distance}" so all three keys (distance,
dirty, distance-dirty) are defined without local-version suffixes.
amotl
changed the title
uvuv. Publish package to TestPyPI.
1 participant
Just maintenance.