-
Notifications
You must be signed in to change notification settings - Fork 760
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better error message for invalid [project]
table
#6419
Comments
We should fall back to building instead of trying to the read the metadata here, as we're doing in other cases, this is a bug. Is there a reason you're using |
@konstin (This is why I wrote seemingly valid)
|
@konstin -- I'm somewhat unsure... It is spec-incompliant. If we accept it here, we risk false negatives for other projects. |
Oh right, because it's not dynamic like in the other cases. We should change the error message with a note about the |
The toml crate doesn't give us this information unfortunately, so we can add better context to the error message: toml-rs/toml#778 |
[project]
table
We got user reports where users were confused about why they can't use `[project.urls]` without other `pyproject.toml`. This PR adds a hint that (according to PEP 621), you need to set `project.name` when using any `project` fields`. (PEP 621 also requires `project.version` xor `dynamic = ["version"]`, but we check that later.) The intermediate parsing layer to tell apart syntax errors from schema errors doesn't incur a performance penalty according to epage (toml-rs/toml#778 (comment)). Closes #6419 Closes #6760
We got user reports where users were confused about why they can't use `[project.urls]` without other `pyproject.toml`. This PR adds a hint that (according to PEP 621), you need to set `project.name` when using any `project` fields`. (PEP 621 also requires `project.version` xor `dynamic = ["version"]`, but we check that later.) The intermediate parsing layer to tell apart syntax errors from schema errors doesn't incur a performance penalty according to epage (toml-rs/toml#778 (comment)). Closes #6419 Closes #6760
We got user reports where users were confused about why they can't use `[project.urls]` without other `pyproject.toml`. This PR adds a hint that (according to PEP 621), you need to set `project.name` when using any `project` fields`. (PEP 621 also requires `project.version` xor `dynamic = ["version"]`, but we check that later.) The intermediate parsing layer to tell apart syntax errors from schema errors doesn't incur a performance penalty according to epage (toml-rs/toml#778 (comment)). Closes #6419 Closes #6760
Hey Astral team!
I found an interesting behavior around installing a git based project that is managed by poetry (as opposed to any other build system).
Since the name of the project is defined under the
tool.poetry
section uv fails to pick it up when reading the pyproject.toml file.I'm not sure if this is considered Poetry's fault, but pip definitely succeeds in installing this exact package. I have not checked whether this issue can be also replicated locally with a relative path package.
Many thanks 🙏
What Happens
uv fails to install a (seemingly) valid python dependency. pip successfully installs this project.
Expected Behavior
uv should install the package
Reproduction
outputs:
uv --version
Platform
macOS Sonoma
The text was updated successfully, but these errors were encountered: