Unfortunately, it doesn't look likebuild.util.project_wheel_metadata obviates this behavior. For example, the 'metadata' returned only includes the field-based metadata. It doesn't include other files in the metadata such as entry points. It's a lot more difficult to construct the full metadata because it requires multiple files, and to achieve that, pep517 constructs an in-memory zipfile.

Also a bit of a nitpick, but I don't see how "wheel" is relevant to all of these functions. A wheel isn't generated; only the project metadata. I'd like to see a function that doesn't involve irrelevant words likeutil andwheel to get the metadata.

Unfortunately, it doesn't look likebuild.util.project_wheel_metadata obviates this behavior. For example, the 'metadata' returned only includes the field-based metadata. It doesn't include other files in the metadata such as entry points. It's a lot more difficult to construct the full metadata because it requires multiple files, and to achieve that, pep517 constructs an in-memory zipfile.

We can introduce further helpers to make that possible.

Also a bit of a nitpick, but I don't see how "wheel" is relevant to all of these functions. A wheel isn't generated; only the project metadata. I'd like to see a function that doesn't involve irrelevant words likeutil andwheel to get the metadata.

It is the metadata that is generated for the wheel. The name comes from PEP 517.

https://www.python.org/dev/peps/pep-0517/#prepare-metadata-for-build-wheel

A wheel is actually generated as a fallback if the backend does not implement the metadata hook, as recommended.

sdists also contain metadata, which may be different from the wheel, and there is no guarantee that further binary formats that may be introduced in the future must have the same metadata as the wheel.
One way I can imagine this happening is introducing a new format that also takes care of binary dependencies for eg., where we would most likely have different metadata under certain scenarios.

I know I am being a bit conservative about the naming and origin of the data, but I didn't feel like it containing "wheel" in the name really hurt anything. Maybe I am an outlier, but my first questing after seeing a function named "project_metadata" would be "which metadata? from where?", as there are multiple metadata sources.

Oh! I see that pep517already provides this same functionality. Let's get rid of it here.