refactor(internal): move the os/arch detection to repo_utils #2075
Conversation
This file contains 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 also changes the local_runtime_repo to explicitly check for supported platforms instead of relying on a `None` value returned by the helper method. This makes the behaviour exactly the same to the behaviour before this PR and we can potentially drop the need for the validation in the future if our local_runtime detection is more robust. This also makes the platform detectino in `pypi_repo_utils` not depend on `uname` and only use the `repository_ctx`. Apparently the `module_ctx.watch` throws an error if one attempts to watch files on the system (this is left for `repository_rule` it seems and one can only do `module_ctx.watch` on files within the current workspace. This was surprising, but could have been worked around by just unifying code. This splits out things from bazelbuild#2059 and makes the code more succinct. Work towards bazelbuild#260, bazelbuild#1105, bazelbuild#1868.
rickeylev
approved these changes
Jul 18, 2024
| @@ -46,7 +46,7 @@ def _local_runtime_repo_impl(rctx): | |||
| on_failure = rctx.attr.on_failure | |||
|
|
|||
| platforms_os_name = repo_utils.get_platforms_os_name(rctx) | |||
| if not platforms_os_name: | |||
| if platforms_os_name not in ["linux", "osx", "windows"]: | |||
There was a problem hiding this comment.
You can just remove this block; as mentioned in the originating PR, I just had it return None because I knew there were cases it didn't handle, but didn't know what they were. Now that it handles all the cases, we can just assume whatever value is returned is correct.
python/private/repo_utils.bzl
Outdated
| return "windows" | ||
| return os | ||
|
|
||
| def _get_platforms_arch_name(rctx): |
There was a problem hiding this comment.
How about _get_platforms_cpu_name instead? Since it's mapping the value to the @platforms//cpu:<name>, where the term is "cpu", not "arch".
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 also changes the local_runtime_repo to explicitly check for
supported platforms instead of relying on a
Nonevalue returned by thehelper method. This makes the behaviour exactly the same to the
behaviour before this PR and we can potentially drop the need for the
validation in the future if our local_runtime detection is more robust.
This also makes the platform detectino in
pypi_repo_utilsnot dependon
unameand only use therepository_ctx. Apparently themodule_ctx.watchthrows an error if one attempts to watch files on thesystem (this is left for
repository_ruleit seems and one can only domodule_ctx.watchon files within the current workspace. This wassurprising, but could have been worked around by just unifying code.
This splits out things from #2059 and makes the code more succinct.
Work towards #260, #1105, #1868.