uv tries to read `project.name` whenever the `project` table is present

[edgarrmondragon]

Here the package metadata may be at fault (https://github.com/quantile-development/dagster-ext/issues/12), but both pypa/build and Poetry are able to build the project without any issues (even if with missing metadata).

[zanieb]

Thanks for the report!

Technically, I think it's a violation of the specification to exclude the name field when a [project] table exists.

From the relevant document:

The lack of a [project] table implicitly means the build backend will dynamically provide all keys.

The only keys required to be statically defined are: ... name

I believe the problem is that we see a [project] table so we attempt to extract static metadata from the project without calling into a build backend. I guess the argument here is that [project.urls] doesn't explicitly define a [project] table? That seems weird though.

I see a few options:

1. We fallback to dynamic metadata retrieval with the build-backend if the static metadata retrieval fails
2. We special-case implicit [project] table declarations
3. We continue to be strict here and pursue a clarification in the specification

[zanieb]

I'm also reading a bit into the linked issue regarding the implicit table definition — please let me know if you think it's wrong to fail if name is missing even when the project table ([project]) is explicitly defined.

[henryiii]

It's invalid. Tools are supposed to error out. I really dislike that it's required, but not up to me. :) See https://github.com/pypa/cibuildwheel/issues/1064.

[FFY00]

I'm also reading a bit into the linked issue regarding the implicit table definition — please let me know if you think it's wrong to fail if name is missing even when the project table ([project]) is explicitly defined.

If there's a project table, the project.name field must be present, but the project table is not required to be present. If a project table is not present, it means the project is not using PEP 621 metadata, which is perfectly valid.

In this case, it seems the project was mixing the project (PEP 621) and tool.poetry tables when specifying the metadata, which shouldn't really be allowed. I consider this a bug in the build backend.

With this in mind, UV's behavior is correct, however, to achieve better compatibility, I would suggest issuing a warning instead of erroring out in such scenarios.

PS: Feel free to ping me if you have any more issues, or questions, regarding the project metadata, and other issues regarding packaging.

[edgarrmondragon]

In this case, it seems the project was mixing the project (PEP 621) and tool.poetry tables when specifying the metadata, which shouldn't really be allowed. I consider this a bug in the build backend.

I agree, though I wonder if it's worth reporting to the Poetry folks, specially since https://github.com/python-poetry/poetry-core/pull/708 is just waiting to be released, and the frontend is WIP (https://github.com/python-poetry/poetry/pull/9135).