Jon Brandvein

I'm not familiar with subpar's implementation details, but the change looks simple enough, and Douglas already signed off on it.

Hm, actually I don't appear to have merge rights in this repo. Not sure who does. I'll look into that...

After spending some time reviewing subpar vs `--build_python_zip`, here's a summary of the main differences I've found: 1. The standard rules don't give you a way to specify whether or...

Removing myself as I don't have bandwidth atm.

Do you mean Starlark-Based Configuration transitions? +@juliexxia for that. There actually exists a native Python version transition but it's experimental (intended for Google's own Python 2-to-3 transition) and can be...

Setting P4 because this isn't a blocker for 1.0 support.

For `--incompatible_remove_old_python_version_api`, it looks like despite [your recent change](https://github.com/bazelbuild/rules_k8s/commit/4be8e3edbd40b53546d9aac373149727630ae9f5) to update the declared version of `rules_python` to bazelbuild/rules_python@965d4b4a63e6462204ae671d7c3f02b25da37941, the actual version that ends up being used is bazelbuild/rules_python@e6399b601e2f72f74e5aa635993d69166784dde1, according to...

I filed the following issues for fixing some transitive deps to update their dep on rules_python and subpar: * stackb/rules_proto#60 * bazelbuild/rules_docker#729 * google/containerregistry#146 I also sent #289 to workaround...

Update: We still need to come up with a coherent best practice for accessing `@bazel_tools` .bzl files as `bzl_library` targets. On reread, I'm not particularly fond of the clunky workaround...

I agree that "Starlib" is a more proper name for this library. However it might be a breaking change -- certainly for WORKSPACE logic, and perhaps also for other reasons....