As part of the work for #9006, we're migrating Bazel's own use of native Python rules to load these rules from a bzl file. Ideally, the load statements should reference the macros in @rules_python//python:defs.bzl just like user code should. However, this isn't possible for the @bazel_tools repository, which is not allowed to have any external dependencies. Therefore, we fake it by creating //tools/python:private/defs.bzl, which implements the same magic @rules_python does, for use by Bazel only.

Of course, there are other uses of Python rules in Bazel's source tree besides those that appear in @bazel_tools. Currently some of these also reference the same //tools/python:private/defs.bzl file, while others reference a stub @rules_python repository (defined in Bazel's own WORKSPACE) that only contains a stub version of @rules_python//python:defs.bzl; see #9019.

This issue tracks potentially replacing the stub @rules_python with the real thing, and avoiding non-@bazel_tools uses of the //tools/python:private/defs.bzl path.

Counterarguments for doing the former: The stub shouldn't be hard to keep in sync with the real rules_python, and using a stub avoids extra build overhead (and finagling with the WORKSPACE). Counterarguments for doing the latter: It's not particularly harmful to refer directly to the workspace-relative path, and it allows us to easily have a path that works both in @io_bazel and @bazel_tools (in the case of the six dependency).