You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello,
I'm currently wondering what is the proper way of offering a target (py_binary for example) with a fixed toolchain for another bazel workspace.
Problematic
We could think of two workspaces
base
andchild
.base
would offer@base//:print_version
target that is apy_binary
loaded fromload("@base_python//:defs.bzl", "py_binary")
.@base_python
would come from something likepython_register_toolchains(name = "base_python", python_version = "3.9",
.Now, it works as expected inside
base
, but, if achild
bazel workspace loadsbase
, things gets complicated.Main reason is because I don't control
child
rules_python
version and its toolchains.Minimal reproduction
I built an example here: https://github.com/lucasmuna/rules_python_offer_toolchain/
What I tried
--extra_toolchains
flag aiming something like@base_python_toolchains//:x86_64-unknown-linux-gnu_toolchain
;base
rules_python
name (this also solves an olderchild
rules_python
version not having some newer APIs but leads to another issues);@base_python//:defs.bzl
.Some solutions seems to works for a certain setup some for another but none of those were generic enough.
Maybe I'm missing something or maybe I'm not even supposed to follow this path.
I also had some other ideas like:
Any ideas are welcomed :)
Beta Was this translation helpful? Give feedback.
All reactions