Open evgri243 opened 4 months ago
I think you can safely use bzlmod and WORKSPACE configurations (we did this when we cut over from WORKSPACE to bzlmod). It'd be worth a shot before you write it off.
The rules_python maintainers are currently working on adding uv directly to rules_python, too.
I've tried already. TensorFlow is very bazelmod unfriendly at the moment. Your dependencies will try to catch rules_cc transitively and a few other dependencies, and TF won't like it as it tries to patch them extensively...
Here is what I ended up with. Taking rules_python plan to integrate, and they support WORKSPACE file, it if fine for now.
http_archive(
name = "bazel_skylib",
sha256 = "cd55a062e763b9349921f0f5db8c3933288dc8ba4f76dd9416aac68acee3cb94",
urls = [
"https://mirror.bazel.build/github.com/bazelbuild/bazel-skylib/releases/download/1.5.0/bazel-skylib-1.5.0.tar.gz",
"https://github.com/bazelbuild/bazel-skylib/releases/download/1.5.0/bazel-skylib-1.5.0.tar.gz",
],
)
load("@bazel_skylib//:workspace.bzl", "bazel_skylib_workspace")
bazel_skylib_workspace()
# rules_uv and dependencies for platform dependent pip_compile alternative
http_archive(
name = "rules_uv",
strip_prefix = "rules_uv-0.17.0",
url = "https://github.com/theoremlp/rules_uv/releases/download/v0.17.0/rules_uv-0.17.0.tar.gz",
)
http_archive(
name = "bazel_features",
sha256 = "06f02b97b6badb3227df2141a4b4622272cdcd2951526f40a888ab5f43897f14",
strip_prefix = "bazel_features-1.9.0",
url = "https://github.com/bazel-contrib/bazel_features/releases/download/v1.9.0/bazel_features-v1.9.0.tar.gz",
)
load("@bazel_features//:deps.bzl", "bazel_features_deps")
bazel_features_deps()
http_archive(
name = "rules_multitool",
sha256 = "7a86b4653b46a573a5cc25f5a2f05f104f1cbc73a427ab8977293eab0885a241",
strip_prefix = "rules_multitool-0.10.0",
url = "https://github.com/theoremlp/rules_multitool/releases/download/v0.10.0/rules_multitool-0.10.0.tar.gz",
)
load("@rules_multitool//multitool:multitool.bzl", "multitool")
multitool(
name = "multitool",
lockfile = "@rules_uv//uv/private:uv.lock.json",
)
http_archive(
name = "rules_multirun",
sha256 = "0e124567fa85287874eff33a791c3bbdcc5343329a56faa828ef624380d4607c",
url = "https://github.com/keith/rules_multirun/releases/download/0.9.0/rules_multirun.0.9.0.tar.gz",
)
http_archive(
name = "buildifier_prebuilt",
sha256 = "8ada9d88e51ebf5a1fdff37d75ed41d51f5e677cdbeafb0a22dda54747d6e07e",
strip_prefix = "buildifier-prebuilt-6.4.0",
urls = [
"http://github.com/keith/buildifier-prebuilt/archive/6.4.0.tar.gz",
],
)
load("@buildifier_prebuilt//:deps.bzl", "buildifier_prebuilt_deps")
buildifier_prebuilt_deps()
load("@buildifier_prebuilt//:defs.bzl", "buildifier_prebuilt_register_toolchains")
buildifier_prebuilt_register_toolchains()
The only catch here is the private "@rulesuv//uv/private:uv.lock.json". Nevertheless, due to other less friendly dependencies, I am anyway forced to disable visibility check, so that I am fine as well. For anyone deciding to use the code above, copy the context of the lock file and point multitool to it instead._
Ah, gotcha. Thanks for sharing a detailed workaround.
Any chance you can allow import through WORKSPACE file?
Motivation: we depend on TensorFlow repository and using bazelmod is practically impossible until TensorFlow has updated first. They claim to be working on it, but it won't come in the foreseeable future, I guess.
rules_uv seems the most convenient way of generating requirement files for linux/aarch64, linux/amd64 and darwin/arm64 to be further used by rules_python. Sadly, they lack that functionality themselves.