Fall back to PEP 621 project.version before consulting SCM tags
#306
Conversation
This file contains 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
|
I like the progress so far! |
…ible When determining the current version, and if `tool.bumpversion.current_version` is not set, attempt to retrieve the version from `project.version` à la PEP 621. If that setting is not set, or if the version is explicitly marked as dynamically set, then continue with querying SCM tags. When updating the configuration during bumping, if we previously successfully retrieved a PEP 621 version, then update the `project.version` field in `pyproject.toml` as well. We always update, even if the true current version was read from `tool.bumpversion.current_version` instead of `project.version`. The docs have been updated; specifically, the "multiple replacements in one file" howto and the reference for `current_version`. The tests have been adapted: the new `pep621_info` property would otherwise trip up the old test output, and the `None` default would trip up the TOML serializer. Additionally, new tests assert that `project.version` (and correspondingly, the `pep621_info` property) is correctly honored or ignored, depending on the other circumstances.
If the current version is explicitly left empty during the `sample-config` questionnaire, the resulting `tool.bumpversion` table now lacks a `current_version` key, and will fall back to PEP 621 `project.version` (if not dynamic). The instruction text specifically hints at this new functionality.
the-13th-letter
force-pushed
the
pep621-version
branch
from
ed00076 to
6b369fe
Compare
|
This is ready for review now. Code tests are included, and passing. Just about the only thing I'm still unsure of are the documentation changes and the commit message texts: I couldn't build the documentation because I couldn't yet figure out which set of plugins and stuff are needed, and for the commit messages I wonder if they will be included in full in the changelog, and if so, if/how much I should trim them down. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## pep621-version #306 +/- ##
=================================================
Coverage ? 93.83%
=================================================
Files ? 29
Lines ? 1948
Branches ? 204
=================================================
Hits ? 1828
Misses ? 91
Partials ? 29
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
This was referenced Mar 5, 2025
Closed
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.
tool.bumpversion.current_versionis unset, butproject.versionfrompyproject.tomlis usable, then fall back to that value before attempting to consult Git/Mercurial/whatever tags.project.versionis set,and was used as the version source,then update that too, apart fromtool.bumpversion.current_version.1current_versions, indicating thatproject.versionis to be used.Closes #66.
Footnotes
While I previously only wanted to update
project.versioniftool.bumpversion.current_versionwas unset, I now prefer always updatingproject.versionno matter what. On the one hand, it avoids mismatched and stale metadata. On the other hand, my initial implementation already behaved this way, and I actually had trouble concocting a test case with the “only if used as the version source“ behavior that actually passes. (Perhaps some caching or staleness issue?) In any case, this variant is both simpler in code and probably less surprising to users. ↩