Support bumping static version

[fabiopicchi]

Solves #1419

[fhennig42]

Gently bumping this as I really would like to see this merged.

[fabiopicchi]

Would love to see that in as well, but at this point I already migrated completely to uv as a build system.

[cjames23]

Thanks for picking this back up @fabiopicchi, and sorry it sat so long. To be clear up front: the feature itself is something we want (ofek signed off on the concept in #1419), so this is about implementation details, not the idea. A few things need to be addressed before it can merge.

1. It reformats the whole pyproject.toml and drops the user's comments.
The save path goes through save_config(raw_config), but raw_config is loaded with tomllib (a plain dict with no formatting or comments captured), and save_config then runs it through tomlkit.dumps(). tomlkit can't preserve trivia that was never parsed, so the result is a canonicalized file. Every comment and bit of formatting in the user's pyproject.toml is silently lost on a simple hatch version minor. Worth noting that save_config has no other callers today, so this isn't an established path we're extending.

Everywhere else hatch edits TOML it round-trips through a tomlkit document instead. See Project.initialize (src/hatch/project/core.py:434), which does tomlkit.parse(f.read()), mutates, then tomlkit.dumps(...), preserving the rest of the file. Please follow that pattern here: re-read pyproject.toml with tomlkit.parse, set doc['project']['version'], and write it back, rather than reusing raw_config/save_config.

2. --force is ignored for static versions.
The new branch never looks at force, and StandardScheme.update defaults validate-bump to True. So hatch version 1.0.0 --force to intentionally downgrade a static version will fail with "not higher than the original version," which diverges from how the dynamic path behaves. The static path should honor --force the same way (i.e. disable bump validation when it's set).

3. The backend change is inconsistent.
This only changes the wording of the abort message in the hatchling CLI (backend/src/hatchling/cli/version/__init__.py) without implementing the behavior there, so python -m hatchling version <x> still aborts, but now points users at hatch. That couples the backend to the frontend and is confusing for standalone hatchling users. Let's either implement the static bump in the backend too, or revert that message change and keep the feature in hatch only.

4. Tests.
The current test only covers the happy path. Please add cases for: comment and formatting preservation after a bump, --force downgrade, and (depending on how we resolve item 3) the backend behavior.

I know you've since moved to uv, so totally understand if you don't have bandwidth to take this further. Just let me know either way. If you'd rather hand it off, I'm happy to carry it forward from here. Appreciate the work getting it this far.

---

This comment was AI assisted with Claude Code using Opus 4.8

[fabiopicchi]

Hi @cjames23, thanks for the comprehensive feedback. Happy to work on it this week (I will have more time towards the end of it) 🙂

I moved to uv professionally, but I think it is really important that the default python tools are as useful and convenient as we can get them to be! Thanks for your valuable work.

[fabiopicchi]

@cjames23 can we add tomlkit as a dependency to hatchling? Just so we have a reliable way of parsing a toml file while keeping formatting and comments.

I was considering a regex-based approach (maybe even for hatch as the version bump is very simple). However, I am worried that pyproject.toml files might be defined in weird ways (project.version, for instance).

I had a quick look at the PEP, and it seems that the [project] table definition is mandatory, but I cannot say for sure. If we can rely on that, I could go the regex route.

Also, please let me know if the changes I made so far are good or not in terms of quality/style :)

[cjames23]

I think tomlkit is an acceptable dependency for hatchling if it is needed

[fabiopicchi]

@cjames23 at first I thought of implementing this exclusively in hatchling and reuse it from hatch, but I guess a little copying is better than a little coupling in this case (the implementations are similar but not exactly the same).

I couldn't find tests for the version cli in hatchling, where should I add them?

Glad to work on any additional changes if needed.