Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: use rules_python implemented py_runtime, py_runtime_pair, PyRuntimeInfo #1574

Merged
merged 1 commit into from
Nov 24, 2023

Conversation

rickeylev
Copy link
Collaborator

@rickeylev rickeylev commented Nov 21, 2023

This switches over to using the rules_python implementation of py_runtime,
py_runtime_pair, and PyRuntimeInfo for 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:

  • Better compatibility with the builtin rules to make transitioning easier
  • py_binary has an old, possibly defunct (not sure) code path that will look up the
    the PyRuntimeInfo from a flag/implicit attribute.

@rickeylev rickeylev force-pushed the pystar-pyruntime branch 10 times, most recently from b9718f5 to 63ab062 Compare November 22, 2023 21:36
@rickeylev rickeylev changed the title Use rules_python implemented py_runtime feat: use rules_python implemented py_runtime, py_runtime_pair, PyRuntimeInfo Nov 22, 2023
@rickeylev rickeylev force-pushed the pystar-pyruntime branch 4 times, most recently from 22b303a to 0c0e34e Compare November 22, 2023 23:23
@rickeylev rickeylev marked this pull request as ready for review November 23, 2023 00:56
@rickeylev rickeylev requested a review from aignas November 23, 2023 00:57
@@ -13,14 +13,15 @@
# limitations under the License.
"""Providers for Python rules."""

load("@rules_python_internal//:rules_python_config.bzl", "config")
load("//python/private:util.bzl", "IS_BAZEL_6_OR_HIGHER")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


# TODO: load CcInfo from rules_cc
_CcInfo = CcInfo

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")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"],
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: I thought we are not supporting PY2?

@chrislovecnm chrislovecnm added this pull request to the merge queue Nov 24, 2023
Merged via the queue into bazelbuild:main with commit 69abe80 Nov 24, 2023
3 checks passed
@rickeylev rickeylev deleted the pystar-pyruntime branch November 30, 2023 04:01
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants