Always normalize recursive extras in dependency metadata#10794
Always normalize recursive extras in dependency metadata#10794charliermarsh wants to merge 3 commits intomainfrom
Conversation
charliermarsh
force-pushed
the
charlie/flatten-extras
branch
from
a287d85 to
ded17cc
Compare
charliermarsh
force-pushed
the
charlie/flatten-extras
branch
from
ded17cc to
21e42e1
Compare
| }) | ||
| { | ||
| return false; | ||
| } |
There was a problem hiding this comment.
This is pretty weird, but we have a lot of lockfile tests (lock_self_*) that test cases in which a package depends on itself, and puts a version specifier on that dependency. I don't think we can drop those.
For example:
[project]
name = "project"
version = "0.1.0"
requires-python = ">=3.12"
dependencies = ["typing-extensions", "project==0.1.0"]There was a problem hiding this comment.
I'm not fully comfortable with this whole situation, self-dependencies seem to be poorly specified right now...
For example, Hatchling drops the ==0.2.0 in the foo extra here:
[project]
name = "project"
version = "0.1.0"
requires-python = ">=3.12"
dependencies = []
[project.optional-dependencies]
foo = ["project[bar]==0.2.0"]
bar = ["iniconfig"]
[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"
There was a problem hiding this comment.
I tried but couldn't reproduce this:
[project]
name = "hatch-drops-self-specifier"
version = "0.1.0"
[project.optional-dependencies]
foo = ["project[bar]==0.2.0"]
bar = ["iniconfig"]
[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"rm -rf venv
uv venv
uv build
uv pip install --find-links dist hatch-drops-self-specifier --no-cache
cat .venv/lib/python3.*/site-packages/hatch_drops_self_specifier-0.1.0.dist-info/METADATAMetadata-Version: 2.4
Name: hatch-drops-self-specifier
Version: 0.1.0
Provides-Extra: bar
Requires-Dist: iniconfig; extra == 'bar'
Provides-Extra: foo
Requires-Dist: project[bar]==0.2.0; extra == 'foo'
charliermarsh
force-pushed
the
charlie/flatten-extras
branch
from
7b950ea to
543b05a
Compare
|
I might make this part of v0.6, and do a smaller fix for the linked issue. |
## Summary This is a smaller alternative to #10794. If the `Requires-Dist` that we extract statically doesn't match the lockfile metadata, we now go back to the distribution database to double-check. Checking the `Requires-Dist` is itself very cheap, so in the worst case, we're just paying the same cost as prior to this optimization. Closes #10776.
|
(I'll wait with reviewing on how https://discuss.python.org/t/core-metadata-for-self-referential-extras/77793 goes, maybe we don't need to do this because we agree on not flattening) |
|
That conversation is sort of irrelevant for solving #10776 though. The behavior already exists. |
## Summary I needed this for #10794, but it makes sense as a standalone change, since it's much more testable. We can also reuse this in at least one more place.
|
Let's just skip this for now. |
2 participants
Summary
Some build backends flattten recursive extras, while others do not (see: https://discuss.python.org/t/core-metadata-for-self-referential-extras/77793/6). If a build backend does flatten its recursive extras, then if we read requirements from the
pyproject.tomldirectly, and compare those requirements to the build backend-returned metadata (as is the case for, e.g., dynamic versions), the comparison will fail.Instead, the
DistributionDatabasenow always returns metadata with these recursive extras normalized out.Closes #10776.