feat: use rules_python implemented py_runtime, py_runtime_pair, PyRuntimeInfo #1574
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
rickeylev
force-pushed
the
pystar-pyruntime
branch
10 times, most recently
from
b9718f5 to
63ab062
Compare
rickeylev
changed the title
rickeylev
force-pushed
the
pystar-pyruntime
branch
4 times, most recently
from
22b303a to
0c0e34e
Compare
rickeylev
force-pushed
the
pystar-pyruntime
branch
from
0c0e34e to
4f41f19
Compare
aignas
approved these changes
Nov 23, 2023
| """Providers for Python rules.""" | ||
|
|
||
| load("@rules_python_internal//:rules_python_config.bzl", "config") | ||
| load("//python/private:util.bzl", "IS_BAZEL_6_OR_HIGHER") |
There was a problem hiding this comment.
Nit, what about using bazel_features package for this? I know that this adds an extra dep, but we are already using that on with bzlmod setups.
| DEFAULT_STUB_SHEBANG = "#!/usr/bin/env python3" | ||
|
|
||
| DEFAULT_BOOTSTRAP_TEMPLATE = "@bazel_tools//tools/python:python_bootstrap_template.txt" | ||
| DEFAULT_BOOTSTRAP_TEMPLATE = Label("//python/private:python_bootstrap_template.txt") |
There was a problem hiding this comment.
Does this mean we can have a custom template on bazel 6? I think that no, but I am not sure if this was just a fixup of previously broken code due to migration.
| default = "_INTERNAL_SENTINEL", | ||
| values = ["PY2", "PY3", "_INTERNAL_SENTINEL"], | ||
| default = "PY3", | ||
| values = ["PY2", "PY3"], |
There was a problem hiding this comment.
Nit: I thought we are not supporting PY2?
This was referenced Dec 13, 2023
github-merge-queue bot
pushed a commit
that referenced
this pull request
Dec 14, 2023
…der Bazel 6; make python_bootstrap_template public (#1611) This fixes two bugs from #1574: * Bazel 6's py_binary rejects the rules_python Starlark implemented PyRuntimeInfo. * python_bootstrap_template.txt isn't public; this prevents py_runtime from being used outside rules_python itself (e.g. in the python toolchain repos) With Bazel 6, the `py_binary` rule performs a type check of the PyRuntimeInfo value it gets from the toolchain to verify it is an instance of the Java-implemented PyRuntimeInfo class. This type check fails when the provider is implemented in rules_python in Starlark. To fix, make the `py_runtime_info` prefer the builtin PyRuntimeInfo provider when running under Bazel 6. The two providers are (currently) the same, so are mostly interchangable. This satisfies the type check that `py_binary` performs. `py_runtime` as an implicit dependency on `//python/private:python_bootstrap_template.txt`, but that target is only visible to rules python itself. This means the py_runtime targets created in the toolchain repos fail. To fix, make the file public. Fixes #1610
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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 switches over to using the rules_python implementation of
py_runtime,py_runtime_pair, andPyRuntimeInfofor Bazel 6 and higher. Bazel 5 lacks features(specifically provider ctors) to allow enabling it on that version.
This is possible because the rules don't directly use the PyRuntimeInfo provider
(mostly, see below), they only care about the structure of it as exposed from the
ToolchainInfo provider.
Switching the toolchain providers and rules over early allows some development of
the toolchain prior to Bazel 7 and the rest of the rules_python Starlark implementation
being enabled.
The builtin PyRuntimeInfo is still returned and accepted for two reasons:
py_binaryhas an old, possibly defunct (not sure) code path that will look up thethe PyRuntimeInfo from a flag/implicit attribute.