Update rules_python to v0.33.2

[fmeum]

This makes the lockfile independent of OS/arch.

[fmeum]

@aignas Updating to rules_python 0.33.0 results in a CI failure:

Traceback (most recent call last):
	File "/tmp/bazel_qc1GFsIz/out/external/rules_python~/python/private/common/py_binary_rule_bazel.bzl", line 42, column 36, in _py_binary_impl
		return py_executable_bazel_impl(
	File "/tmp/bazel_qc1GFsIz/out/external/rules_python~/python/private/common/py_executable_bazel.bzl", line 106, column 35, in py_executable_bazel_impl
		return py_executable_base_impl(
	File "/tmp/bazel_qc1GFsIz/out/external/rules_python~/python/private/common/py_executable.bzl", line 207, column 46, in py_executable_base_impl
		exec_result = semantics.create_executable(
	File "/tmp/bazel_qc1GFsIz/out/external/rules_python~/python/private/common/py_executable_bazel.bzl", line 269, column 36, in _create_executable
		_create_executable_zip_file(
	File "/tmp/bazel_qc1GFsIz/out/external/rules_python~/python/private/common/py_executable_bazel.bzl", line 526, column 5, in _create_executable_zip_file
		def _create_executable_zip_file(ctx, *, output, zip_file, stage2_bootstrap, runtime_details):
Error: _create_executable_zip_file() got unexpected keyword argument: python_binary_path

Do you have an idea what's up with this?

[aignas]

It's the end of my day, so will look at this tomorrow.

cc @rickeylev, I think this may be something that you might know better.

[aignas]

Created bazelbuild/rules_python#1953 but I am not sure if it is the right fix.

[meteorcloudy]

From //src/test/shell/bazel:bazel_bootstrap_distfile_tar_test:

�[1A�[K�[31m�[1mERROR: �[0mAn error occurred during the fetch of repository 'rules_python~~python~python_3_8_x86_64-unknown-linux-gnu':
   Traceback (most recent call last):
	File "/tmp/bazel_Ubba36tE/out/external/rules_python~/python/repositories.bzl", line 165, column 34, in _python_repository_impl
		rctx.download_and_extract(
Error in download_and_extract: java.io.IOException: Error downloading [https://github.com/indygreg/python-build-standalone/releases/download/20240415/cpython-3.8.19+20240415-x86_64-unknown-linux-gnu-install_only.tar.gz] to /tmp/bazel_Ubba36tE/out/external/rules_python~~python~python_3_8_x86_64-unknown-linux-gnu/temp475338585684382831/cpython-3.8.19+20240415-x86_64-unknown-linux-gnu-install_only.tar.gz: Unknown host: github.com

Looks like

bazel/scripts/bootstrap/bootstrap.sh

Line 43 in d095e2e

--extra_toolchains=@bazel_tools//tools/python:autodetecting_toolchain \

didn't work after upgrading to 0.33.1. We want to use the local python toolchain during bootstrap. @aignas @rickeylev Do you know what's changed?

[rickeylev]

" Unknown host: github.com" is indicating an error downloading from github. I've seen this occasionally and its usually transient. Some of the CI jobs succeeded. I hit retry in CI, but it looks like the same error happened again. Is there some other error indicating its an issue with rules_python? Is this, perhaps, because the CI job is running without network access, and something is trying to download python-build-standalone when it shouldn't be? It looks like there's other fetches of other remote repos, though?

For posterity: a new feature in 0.33+ is the way programs startup has been rewritten. However, it's disabled by default, so you shouldn't see any change in behavior.

using @bazel_tools//python:autodetecting_toolchain

Off-topic from this issue, but: Oh, this is good to know. I've been hoping to get rid of this toolchain, but it appears to be a bit more load bearing than I thought. FYI: Using the bazel_tools one will become harder to use over time. It references the builtin-Bazel python providers, which rules_python tries to gracefully support, but those objects don't have all the same fields, so it can only do so much. Instead, after upgrading to 0.33, you can use @rules_python//python:autodetecting_toolchain (you could do it earlier, but prior to 0.33 it's an alias to bazel_tools, so not much point)

[rickeylev]

The particular repo initiating that download is: rules_python~~python~python_3_8_x86_64-unknown-linux-gnu

The logs don't tell enough as to why, though.

The only other thing that comes to mind is something with pip dependencies? Something relating to @aignas changes? I don't recall those changes forcing usage of the hermetic runtimes, though.

That 3.8 is being downloaded is kind of weird.

The 3.8 being downloaded (or attempted to be used) reminds me of something we found with bzlmod. I forget the details, but it as something like, if no default python version was specified, it would use the first entry in the versions array, which happens to be 3.8. But this only happened if...I can't remember. If something else wasn't configured right. Or something.

[aignas]

FYI, I have tagged a new release which should fix the toolchain problems you've been experiencing with 0.33.1. See bazelbuild/bazel-central-registry#2292.

[meteorcloudy]

@aignas Thank you so much!!

[rickeylev]

fyi, when importing rules_python 0.33 into google, I found one of the Bazel Java tests (PythonStarlarkApiTest.runtimeSandwich) failed due to bazelbuild/rules_python#1992. If this shows up on the Bazel side of things, we can just delete that test -- it's just verifying the PyRuntimeInfo object bazel exposes can be accessed from Starlark, but there's plenty of other tests that indirectly cover that (both in rules_python in OSS, rules_python in google, and elsewhere in the Bazel Java tests).

[meteorcloudy]

@rickeylev Thanks for the heads up, we'll do that!

[meteorcloudy]

🎉