@rickeylev @aignas I need help here. I am registering the test target platform as an execution platform to ensure compatibility with the new test toolchain, but that runs into an issue I'm planning to resolve in the future by bazelbuild/bazel#26019: every py_executable has an exec dependency on a C++ toolchain through launcher_maker.

In this particular case, I could work around this by transitioning to the host platform rather than the fixed platform LINUX_X86_64. Would that be acceptable?

The launcher_maker is only needed for windows, so that dependency shouldn't be occurring for linux et al. I see it's refering to @bazel_tools//tools/launcher:launcher_maker directly, though. IIRC, bazel_tools has a select() to point that to something no-op. So it shouldn't still be requiring a C++ toolchain?

Would it help if we changed py_executable to point to an alias with select()?

alias(
    name = "launcher_maker",
    actual = select({
        "@platforms//os:windows": "@bazel_tools/tools/launcher:launcher_maker",
        "//conditions:default": "//python:none",
    })

py_executable has an optional dependency on the cc toolchain regardless, but I'm assuming that's OK.

Yes, it's only needed for Windows, but with the current setup within Bazel, every OS pays the price (the exec dep on a C++ toolchain).

The selects (both the one that exists in Bazel and the one you suggest) apply after the exec transition and thus can't distinguish between a build that targets Windows and a build that doesn't. That's why I'm planning to introduce a toolchain for the launcher maker, which can match on both exec and target platform simultaneously.

However, this will require Bazel feature detection or a new BCR module for the launcher maker, so it won't help here (at least not soon).

I think I follow, I think 🙃

Transitioning to the host platform is probably ok.

I now realized that this wouldn't work on Windows hosts. What do you think of registering a fake C++ toolchain? I've done that on other analysis tests and it did work there.

Sgtm. There are a couple fake cc tool chains in tests/support/cc_toolchain that might just work already

I updated the title and description to better reflect the what/why -- can you please confirm/correct?

CI is passing after your recent change, so I think this is otherwise ready?

After the title/description is confirmed, we can queue to merge.

Does this PR mean that users using rules_python will have to depend on a C++ toolchain eventually? Or will this limitation be fixed in the future (bazelbuild/bazel#26019)?