build: report internal build dependency provenance - #2509
Open
rwgk wants to merge 1 commit into
Open
Conversation
Contributor
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
Contributor
Author
|
/ok to test |
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Related to #2468. The stacked follow-up, #2510, addresses dependency selection itself.
PEP 517 build hooks execute in environments where the dependency actually imported at build time is not always obvious from the surrounding workflow. A locally built wheel, an editable or source installation, and a released package can all be present or eligible. Without explicit provenance in the build log, a successful build can appear to validate one combination of sources while actually using another, and discrepancies between local and CI builds can be unnecessarily difficult to diagnose.
This PR reports the internal dependency that each build hook imported, at the point where it is used:
cuda.bindingsbuild reports thecuda-pathfinderversion and package directory.cuda.corebuild reports thecuda-pathfinderversion and package directory.cuda.corebuild reports thecuda-bindingsversion and package directory.The resulting messages have this form:
Both pieces of information are useful. A version alone may not distinguish a local artifact from an index-provided installation, while a path alone does not identify which release or development version was imported. Together they make the build log direct, self-contained evidence of dependency provenance.
The messages are written to stderr so they remain visible in build logs. This PR does not change dependency resolution or validation behavior. While touching the duplicated
cuda-pathfinderimport helpers, it also keeps them equivalent and narrowly replaces theiros.pathoperations withpathlib.Pathoperations.