We should allow pip.parse to more easily use the default python the toolchains have configured. This is for a couple reasons: correctness, ease of use, and ease of maintainability.

Right now, a sub-module has two options:

1. Assume what the default version is. This isn't safe, since the root module or rules_python may change it arbitrarily, and then various MODULE-level configuration breaks.
2. Explicitly request the version they want. This works, but requires the module to manually wire the toolchain interpreter to pip using the interpreter.install helper extension; this is annoying configuration.

(1) isn't a real option for submodules because the breakage happens at the MODULE-configuration level. If it were at runtime, that would be less of an issue -- most code is fairly compatible across versions.

For (2), pinning to a specific python version is both a pro and con. Most code is fairly compatible across versions, so pinning to a specific Python version is usually overkill. It's something libraries should opt-into if they really need it.

Doing (2) also raises the risk that the pip and toolchain parts don't agree -- if you pin your pip to a specific version, then you should also use the version-aware py_* rules. But that's easy to forget.

Allowing pip.parse to use the default python version makes a lot of this go away. (not entirely, but we can't address that until the pip processing is interpreter-agnostic).

What I'm thinking is an unadorned pip.parse call using the default python, e.g.

pip.parse(
  hub_name = "pip",
  requirements = "//:requirements.in"
)

Will automatically use whatever the is_default=True interpreter is that the toolchain configured.

Another approach would be allow the interpreter extension to reference the default, but it seems cleaner, and represents the user intent better, if we don't require the the interpreter extension to "middleman" it like that.