uv build backend lowercases package name in wheel metadata

[john-hen]

Summary

When using the uv_build build backend to create a distribution wheel, the package name is lowercased / normalized even though it shouldn't be.

For example, with a project that has just src/foo/__init__.py and this pyproject.toml

[project]
name = "Foo"
version = "1.0.0"
description = "Foos the foo."

[build-system]
requires      = ["uv_build == 0.9.7"]
build-backend = "uv_build"

running uv build --wheel produces dist/foo-1.0.0-py3-none-any.whl that when inspected as a .zip archive contains this METADATA file:

Metadata-Version: 2.3
Name: foo
Version: 1.0.0
Summary: Foos the foo.

The project name is incorrectly lowercased to "foo" when it was specified as "Foo".

Other build backends don't do that. For example, when using Hatchling with

[build-system]
requires = ["hatchling == 1.27.0"]
build-backend = "hatchling.build"

or Flit with

[build-system]
requires      = ["flit_core == 3.12.0"]
build-backend = "flit_core.buildapi"

[tool.flit.module]
name = "foo"

In those cases, the METADATA file inside the wheel contains the expected

Metadata-Version: 2.4
Name: Foo
Version: 1.0.0
Summary: Foos the foo.

Normalization "should be done before lookups and comparisons", i.e., packages with the same normalized name are considered to be identical. But here it is applied to metadata upon publication. This is quite surprising when coming from other build backends, especially as it's typically only noticed after pushing to PyPI and thus can only be fixed in a subsequent release.

Platform

Ubuntu 24.04 and Windows 11

Version

uv 0.9.7

Python version

No response

[caschb]

This seems to be done on purpose, as the metadata for the name is saved as a PackageName which automatically normalizes the string.

uv/crates/uv-build-backend/src/metadata.rs

Line 582 in 101d0e2

name: PackageName,

uv/crates/uv-normalize/src/package_name.rs

Lines 11 to 16 in 101d0e2

	/// The normalized name of a package.
	///
	/// Converts the name to lowercase and collapses runs of `-`, `_`, and `.` down to a single `-`.
	/// For example, `---`, `.`, and `__` are all converted to a single `-`.
	///
	/// See: <https://packaging.python.org/en/latest/specifications/name-normalization/>

I agree with you that this is incorrect/unnecessary according to the packaging documentation
Even in their example here they use an unnormalized string for the Name field.

[caschb]

I have an initial solution for this, if the uv folks do consider this a bug and are interested I could open a draft PR and we could work from there, just let me know.

[charliermarsh]

I think we're unlikely to change our use of normalized names in general (it is intentional) but we could address this case if it's not too invasive.

[caschb]

I think we're unlikely to change our use of normalized names in general (it is intentional) but we could address this case if it's not too invasive.

Ok, I created a PR so you can judge if it's appropriate for the project.
I made sure the change didn't touch anything outside this one case.

[charliermarsh]

Thank you for the clear PR and test case.

[charliermarsh]

Fixed in #16548.