Add exports for core Python logic that's bundled with Bazel

[brandjon]

This series of commits adds exports to rules_python for Bazel-packaged Python rule logic. Most importantly, this includes the native rules and providers like py_binary and PyInfo, but it also includes Starlark-defined constructs that are distributed in @bazel_tools.

Work toward bazelbuild/bazel#8893. These exports constitute the new API we wish to migrate users to for that change.

Blocked on:

• Still needs redirects for the runfiles library
• Need to rename the canonical workspace name from @io_bazel_rules_python to @rules_python (Rename canonical workspace to @rules_python #203)

[oquenchil]

LGTM

[brandjon]

@clintharrison: I got an email of your post but can't see a comment here, did you delete it or is github being weird?

In response to your point about warning when a deprecated API (python.bzl) is used: While (in my opinion) there's not necessarily a clear consensus about whether to use or proscribe print() for deprecation warnings, I personally try to avoid it. The philosophy is to instead make warnings into failures. This may block a user from upgrading to a new version of the repo until they migrate, but that's more acceptable for repo rules than it is for Bazel itself (since users have more flexibility about not upgrading).

In addition, we can sometimes make it a soft failure that can be bypassed during a transition period (a la Bazel's --incompatible_* flags). In this case it might be done by having the macro inject an extra dependency on a target that fails unless a certain flag is passed on the command line (implemented using Starlark-based configurations / build settings).

[clintharrison]

@clintharrison: I got an email of your post but can't see a comment here, did you delete it or is github being weird?

In response to your point about warning when a deprecated API (python.bzl) is used: While (in my opinion) there's not necessarily a clear consensus about whether to use or proscribe print() for deprecation warnings, I personally try to avoid it. The philosophy is to instead make warnings into failures. This may block a user from upgrading to a new version of the repo until they migrate, but that's more acceptable for repo rules than it is for Bazel itself (since users have more flexibility about not upgrading).

In addition, we can sometimes make it a soft failure that can be bypassed during a transition period (a la Bazel's --incompatible_* flags). In this case it might be done by having the macro inject an extra dependency on a target that fails unless a certain flag is passed on the command line (implemented using Starlark-based configurations / build settings).

Sorry, I intended on reposting it as a full comment, rather than an inline one, but you beat me to the reply :)

Thanks for explaining the reasoning there -- I think that approach makes a lot of sense!