Open ofek opened 7 months ago
Thanks, I can take a look.
FWIW, I think the spec doesn't make it clear that the expectation is for the mismatched field (requested revision) to match what was originally specified, rather than the final commit hash.
This clarification is worth a spec update PR on the packaging.python.org page.
I think the requested revision should match what the user specified (or did not) indeed. If you want to encode more data it looks like the PEP has this text which was not ported over to the living document spec:
- If the installer could discover additional information about the requested revision, it MAY add a
resolved_revision
and/orresolved_revision_type
field. If no revision was provided in the requested URL,resolved_revision
MAY contain the default branch that was installed, andresolved_revision_type
will bebranch
. If the installer determines thatrequested_revision
was a tag, it MAY addresolved_revision_type
with valuetag
.
This clarification is worth a spec update PR on the packaging.python.org page.
The text has been updated: https://packaging.python.org/en/latest/specifications/direct-url-data-structure/#vcs-urls
Thanks. Probably not gonna fix it immediately, will require some internal refactors.
Have the refactors been completed?
I'm in the process of adding support for UV in Hatch and I noticed that the test suite is failing because of a difference in how UV writes
direct_url.json
vs pip, specifically therequested_revision
field. The reason this is read is to determine whether dependencies are in sync.Given the following requirements:
The following command shows different results based on which installer was used:
UV:
pip: