chore!: drop WORKSPACE support from rules_python

[aignas]

All of the bazel versions that we support support bzlmod and the support for
WORKSPACE is being dropped in other rulesets as well. At some point new
versions of our dependencies will make it more and more difficult to carry
support for both, so in order to make the codebase easier to maintain, let's
drop the support.

Regarding whether we should call the next version 2.1 or 3.0, I am not sure.
For bzlmod users nothing is changing, so Semver is respected, whereas for
WORKSPACE users, rules_python cannot be used anymore, it's as if 2.1 no
longer exists for WORKSPACE users, so I think it is fine to call the release
2.1.

Summary:

• Remove examples.
• Remove docs.
• Start dropping symbols and support as well.

NOTE: this may need to wait until we discuss out what we are doing with our downstream users:

• https://github.com/protocolbuffers/protobuf/blob/main/WORKSPACE
• add more

Work towards #2950

[gemini-code-assist]

Code Review

This pull request focuses on the deprecation and removal of legacy WORKSPACE support in favor of bzlmod for PyPI dependency management. It includes the deletion of several WORKSPACE files across examples, updates to documentation to reflect the shift, and the removal of WORKSPACE-specific logic and symbols from the core build rules. Additionally, the PR applies minor formatting improvements to various Python scripts throughout the repository. I have no feedback to provide.

[dougthor42]

Looks like autoformatting snuck in.

Either wrap in # fmt: off # fmt: on comments, or tell formatter to ignore this file. This one is intentionally asserting some python AST parsing.

[aignas]

The toolchain_target_settings_test fails on Bazel 7.7.0 because the config.add_transition_setting + apply_config_settings_attr interaction relies on label string formatting that is inconsistent across Bazel versions.

Root cause:

Bazel 8.0 release notes state:

[Incompatible] All labels in Bazel error messages, log output, Build Event Protocol, etc. are now prefixed with double-at (@@) instead of single-at (@) where applicable, to properly denote that they contain canonical repo names.

The flow:

1. config.add_transition_setting(setting = "//:family") calls str(tag.setting) in config.bzl
2. That string lands in EXTRA_TRANSITION_SETTINGS -> TRANSITION_LABELS -> transition inputs/outputs
3. apply_config_settings_attr calls str(key) on the Label from config_settings = {"//:family": "custom"}
4. The transition output key from step 3 must exactly match the input key from step 2

On Bazel 7, str(Label(...)) produces single-@ labels (e.g. @//:family), but str(tag.setting) for attr.label in a module extension tag can produce a different form (e.g. @module_under_test//:family). This mismatch means the transition output key does not match any input key -> the family flag stays at its default ("prebuilt") -> the is_prebuilt config_setting matches -> the gated default toolchain resolves -> the build succeeds when it should fail.

Bazel 8 fixed this with the @@ canonicalization change, making label strings consistent across all APIs. This is tracked by the umbrella issue bazelbuild/bazel#11128 "Support workspace label prefixes in Starlark config and platform APIs", which encompassed related sub-issues (#9065, #10152, #10499, #10927).

Fix: Restrict toolchain_target_settings_test to bazel_versions = ["8.5.1", "9.1.0"] where cross-repo transition labels resolve consistently.

[aignas]

Sorry for the LLM analysis, but I was a little baffled why this started failing now. The rest has been crafted with Artisanal Intelligence.