This is the general tracking issue for re-implementing the Bazel-bundled Python rules in Starlark in the rules_python repo.

The Bazel-side issue is bazelbuild/bazel#15897

As of now (Feb 2023), the Bazel bundled rules (not providers or flags, though) have all been re-implemented in Starlark. They will used in Bazel 7. Hooks for low-level Bazel behaviors the Python rules need are exposed to the rules_python repo. So now this is mostly a matter of copying that code over here, cleaning it up, and flushing out any missing hooks.

TODO

• Copy Bazel code over to rules_python
• Re-implement Bazel tests in rules_python
• Re-implement flags in Starlark
• Setup a CI config that uses e.g. bazel=rolling to get access to pre-release bazel versions
• Enable pystar by default

That's the high level gist, some lower level TODOs are:

• Implement compatibility shim so rules_python and Bazel rules can interoperate to some degree
• Deprecate and remove Bazel-bundled flags
• Deprecate and remove Python-related parts in @bazel_tools

An optional bonus thing is to backport the low-level hooks to 5.x and/or 6.x. This makes them available sooner, so that we don't have to wait for Bazel 7. There isn't a ton to backport (I intentionally made them to be amenable to this idea), but there's several small pieces. The two general pieces are exposing the flags as fragments and the py_internal object:

• py_internal object and it's backing pieces:
  • PyBuiltins.java
  • BazelPyBuiltins.java
  • py_internal name declaration in BazelRuleClassProvider.java
  • py_internal name override in exports.bzl
  • py_internal.bzl
• Configuration fields (Bazel builtin flags); Strictly speaking, only flags that don't have a fixed set of values (e.g arbitrary string or labels) need to be made available. Other flags can be "wrapped" in a regular Starlark-defined flag by just having an exhaustive listing of config_settings
  • --python_path and --python_top from BazelPythonConfiguration; note, however, that --python_top is supposed to be unused (superceded by toolchains) and --python_path is probably unused (unclear; some comments indicate it might be used as part of windows support)
  • --build_python_zip from PythonConfiguration.java; note, however, it, too, can be replicated in Starlark by using platforms or the py_internal.get_current_os_name() helper.