fix: load target_platforms through the hub #2781
Merged
Conversation
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
This PR moves the parsing of `Requires-Dist` to the analysis phase within the `whl_library_targets_from_requires` macro. The original `whl_library_targets` macro has been left unchanged so that I don't have to reinvent the unit tests - it is well covered under tests. Before this PR we had to wire the `target_platforms` via the `experimental_target_platforms` attr in the `whl_library`, which means that whenever this would change (e.g. the minor Python version changes), the wheel would be re-extracted even though the final result may be the same. This also cleans up the code by removing left over TODO notes or code that no longer make sense. Work towards bazel-contrib#260, bazel-contrib#2319
|
The implementation that handles the dep resolution for |
aignas
changed the title
rickeylev
approved these changes
Apr 20, 2025
There was a problem hiding this comment.
This PR moves the parsing of Requires-Dist to the analysis phase
I don't see this part? I think I see it moving into the loading phase. Just update the description if so.
Analysis phase would be more like: a custom flag implementation that uses FeatureFlagInfo to affect select() resolutions.
refactor/fix ...
Since it's a fix, please give the title "fix" and update the changelog appropriately.
config.bzl.tmpl.bzlmod
Outdated
There was a problem hiding this comment.
This is now used in the hub_repository.bzl.
aignas
changed the title
aignas
added a commit
that referenced
this pull request
Apr 20, 2025
This PR moves the parsing of `Requires-Dist` to the loading phase within the `whl_library_targets_from_requires` macro. The original `whl_library_targets` macro has been left unchanged so that I don't have to reinvent the unit tests - it is well covered under tests. Before this PR we had to wire the `target_platforms` via the `experimental_target_platforms` attr in the `whl_library`, which means that whenever this would change (e.g. the minor Python version changes), the wheel would be re-extracted even though the final result may be the same. This refactor uncovered that the dependency graph creation was incorrect if we had multiple target Python versions due to various heuristics that this had. In hindsight I had them to make the generated `BUILD.bazel` files more readable when the unit test coverage was not great. Now this is unnecessary and since everything is happening in Starlark I thought that having a simpler algorithm that does the right thing always is the best way. This also cleans up the code by removing left over TODO notes or code that no longer make sense. Work towards #260, #2319 (cherry picked from commit a19e1e4)
aignas
added a commit
to aignas/rules_python
that referenced
this pull request
Apr 27, 2025
This just adds the code back at the original state before the following PRs have been made to remove them: bazel-contrib#2629, bazel-contrib#2781. This has not been hooked up yet in `evaluate_markers` and `whl_library` yet and I'll need extra PRs to do that. No CHANGELOG entries for now, will be done once the integration is back. Work towards bazel-contrib#2830
github-merge-queue bot
pushed a commit
that referenced
this pull request
Apr 27, 2025
This just adds the code back at the original state before the following PRs have been made to remove them: #2629, #2781. This has not been hooked up yet in `evaluate_markers` and `whl_library` yet and I'll need extra PRs to do that. No CHANGELOG entries for now, will be done once the integration is back. Work towards #2830
aignas
added a commit
that referenced
this pull request
Apr 29, 2025
This just adds the code back at the original state before the following PRs have been made to remove them: #2629, #2781. This has not been hooked up yet in `evaluate_markers` and `whl_library` yet and I'll need extra PRs to do that. No CHANGELOG entries for now, will be done once the integration is back. Work towards #2830 (cherry picked from commit 61c91fe)
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.
This PR moves the parsing of
Requires-Distto the loading phasewithin the
whl_library_targets_from_requiresmacro. The originalwhl_library_targetsmacro has been left unchanged so that I don't haveto reinvent the unit tests - it is well covered under tests.
Before this PR we had to wire the
target_platformsvia theexperimental_target_platformsattr in thewhl_library, which meansthat whenever this would change (e.g. the minor Python version changes),
the wheel would be re-extracted even though the final result may be the
same.
This refactor uncovered that the dependency graph creation was incorrect
if we had multiple target Python versions due to various heuristics that
this had. In hindsight I had them to make the generated
BUILD.bazelfiles more readable when the unit test coverage was not great. Now this
is unnecessary and since everything is happening in Starlark I thought
that having a simpler algorithm that does the right thing always is the
best way.
This also cleans up the code by removing left over TODO notes or code
that no longer make sense.
Work towards #260, #2319