Currently, hatchling stores the exact name given in METADATA. But it normalizes the version number in METADATA. So this:
[project]
name = "A_b-c.d"
version = "2026.08.10"
produces this:
Metadata-Version: 2.5
Name: A_b-c.d
Version: 2026.8.10
On the PyPI page, the stylized name is shown, but the version number is not stylized (since it's not in the metadata).
I've looked over the standards, and I cannot find anything that says the version number must be normalized before storing it. Filenames and .dist-info need the normalized number, of course, just like they need the normalized name, but the METADATA itself is used to show the users original intent for the stylization of the name.
I expect this is mostly an oversight due to the design, since it's very common to store Version instead of the original string, and for performance reasons, we don't keep the leading 0's. To be fair, it seems to be a very common oversight, though, shared by flit-core and even all pyproject-metadata projects, including scikit-build-core.
My CalVer projects almost always get a issue eventually from someone who sees the tags as YYYY.MM.DD (which is required to get them to sort nicely) and complains that the PyPI page doesn't show it that way.
See:
(Also we discussed this a bit a while back on Discord)
Currently, hatchling stores the exact name given in METADATA. But it normalizes the version number in METADATA. So this:
produces this:
On the PyPI page, the stylized name is shown, but the version number is not stylized (since it's not in the metadata).
I've looked over the standards, and I cannot find anything that says the version number must be normalized before storing it. Filenames and
.dist-infoneed the normalized number, of course, just like they need the normalized name, but the METADATA itself is used to show the users original intent for the stylization of the name.I expect this is mostly an oversight due to the design, since it's very common to store
Versioninstead of the original string, and for performance reasons, we don't keep the leading 0's. To be fair, it seems to be a very common oversight, though, shared by flit-core and even all pyproject-metadata projects, including scikit-build-core.My CalVer projects almost always get a issue eventually from someone who sees the tags as
YYYY.MM.DD(which is required to get them to sort nicely) and complains that the PyPI page doesn't show it that way.See:
(Also we discussed this a bit a while back on Discord)