[drake_bazel_download] Upgrade MODULE.bazel

[jwnimmer-tri]

See bazel-contrib/rules_python#2226 for some background. There is now an exec_interpreter that we need to actively disable, or else Bazel will try to download and run something random from the internet (e.g., a Python 3.11 tarball) which fails when running as root (e.g., in CI), due to this code.

---

This change is 

[jwnimmer-tri]

+@xuchenhan-tri we have basically no subject matter experts on Bazel toolchains. Would you be willing to make an attempt at both reviews of this PR, please?

[xuchen-han]

For sure, on it now.

[xuchen-han]

x2
I got most background info I need from https://bazel.build/extending/toolchains, but I still have one question (that the linked rules_python PR didn't quite help me understand).

Reviewed 2 of 2 files at r1, all commit messages.
Reviewable status: 1 unresolved discussion, platform LGTM from [xuchenhan-tri] (waiting on @jwnimmer-tri)

---

drake_bazel_download/BUILD.bazel line 13 at r1 (raw file):

py_exec_tools_toolchain(
    name = "python_no_exec_tools",
    exec_interpreter = "@rules_python//python:none",

BTW, what's missing from my understanding is what exactly is exec_interpreterand when/where it's used.

[jwnimmer-tri]

Reviewable status: 1 unresolved discussion, platform LGTM from [xuchenhan-tri] (waiting on @xuchenhan-tri)

---

drake_bazel_download/BUILD.bazel line 13 at r1 (raw file):

Previously, xuchenhan-tri wrote…

BTW, what's missing from my understanding is what exactly is exec_interpreterand when/where it's used.

It's used for precomputing the *.pyc bytecode files as part of the bazel build //... action in order to reduce startup times of python programs. If you are cross-compiling python code (where your interpreter differs between your build platform and the built platform), it might need to be different than the main toolchain.

I am not sure what / whether any of that should go into code comments here?

[xuchen-han]

drake_bazel_download/BUILD.bazel line 13 at r1 (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

It's used for precomputing the *.pyc bytecode files as part of the bazel build //... action in order to reduce startup times of python programs. If you are cross-compiling python code (where your interpreter differs between your build platform and the built platform), it might need to be different than the main toolchain.

I am not sure what / whether any of that should go into code comments here?

Ok, AFAICT this is a new feature that rules_python introduced that we don't need but is hurting CI. Probably making that clear is helpful in the comment.

As I was reading the change I was wondering: "we disabled something; would that cause something to fail?". From what I understand now, the answer is no.

[jwnimmer-tri]

Reviewable status: 1 unresolved discussion, platform LGTM from [xuchenhan-tri] (waiting on @xuchenhan-tri)

---

drake_bazel_download/BUILD.bazel line 13 at r1 (raw file):

Previously, xuchenhan-tri wrote…

Ok, AFAICT this is a new feature that rules_python introduced that we don't need but is hurting CI. Probably making that clear is helpful in the comment.

As I was reading the change I was wondering: "we disabled something; would that cause something to fail?". From what I understand now, the answer is no.

I've expanded the top-of-file comment to hopefully help.

[xuchen-han]

Reviewed 1 of 1 files at r2, all commit messages.
Reviewable status: complete! all discussions resolved, platform LGTM from [xuchenhan-tri] (waiting on @jwnimmer-tri)

---

drake_bazel_download/BUILD.bazel line 13 at r1 (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

I've expanded the top-of-file comment to hopefully help.

Thanks.