Support multiple conda environment in the same bazel project

[tetractius]

I found myself in a not-really-bazelian use case recently, needing to support 2 or more conda environments in the same Bazel project tree.

At first, even if the great rules_conda supports the registration of multiple Python toolchains, it is impossible to specify which environment to use for a specific Python target.

However, rules_conda actually generates a BUILD file with a Python runtime.
That is if you define the following in the WORKSPACE:

http_archive(
    name = "rules_conda",
    sha256 = "ee187c4902f5f8da85fcba9943064fd38b2a75f80ed0a2844b34cf9e27cb5990",
    url = "https://github.com/spietras/rules_conda/releases/download/0.2.0/rules_conda-0.2.0.zip"
)

load("@rules_conda//:defs.bzl", "load_conda", "conda_create", "register_toolchain")

load_conda()

conda_create(
    name = "conda_env1",  # name of the environment
    environment = "//:environment1.yml", 
)

conda_create(
    name = "conda_env2",  # name of the environment
    environment = "//:environment2.yml",  
)

# in bazel 6.2.1, even though this does not give any error, only the first toolchain will be used by default for python targets
register_toolchain(env = "conda_env1")
register_toolchain(env = "conda_env2")

You can actually query the external conda_env to be generated.

bazel query 'filter(".*conda_env.*", //external:*)'
//external:conda_env1
//external:conda_env2

So you can inspect each of those to look for a python_runtime

bazel query 'filter(".*python_runtime*", @conda_env1//:*)'
@conda_env1//:python_runtime
bazel query 'filter(".*python_runtime*", @conda_env2//:*)'
@conda_env2//:python_runtime

If you need to know what files are a part of this python_runtime (and you feel adventurous), you can also add a --output=build.

So once you know the Python runtime, if you have a Python target in app/BUILD, say something like:

load("@rules_python//python:defs.bzl", "py_binary")

py_binary(
    name = "main",
    src = glob(["**/*.py"]),
)

You can then ensure a target is run with a specific Python runtime by doing the following:

bazel run --incompatible_use_python_toolchains=false --python_top=@conda_env1//:python_runtime //app:main
# or 
bazel run --incompatible_use_python_toolchains=false --python_top=@conda_env2//:python_runtime //app:main

you need to use --incompatible_use_python_toolchains=false if you want to use --python_top flag to specify the runtime.
With --incompatible_use_python_toolchains=true (that is the default), --python_top cannot be specified, and by omitting it, bazel will use the first conda environment registered for all the python targets by default - in this example, coda_env1

[spietras]

Interesting findings. Since you have already emerged deeply into Bazel's way of working, your insight is valuable. Let me ask you directly: Do you think it is possible for rules_conda to make it easier for people to use different environments for different targets while using Python toolchains? If yes, do you have any ideas on how to achieve it?

[tetractius]

Unfortunately, I have tried to find different ways to set a specific python_runtime per target, but it is impossible with the current official Python rules (https://bazel.build/reference/be/python). No, unless re-implementing all those rules from scratch at least.

The only way seems to be to use the --python_top.

This means that if you have a big repo with two or more different Python targets relying on different conda environments (which is totally acceptable environment - that is the point of conda/virtualenv, after all, right?), you will have to have two bazel invocation.

This also means you cannot have two different py_library, created with different conda environments, depending on each other. This might be a good thing from a certain point of view.

I guess the real point is that Bazel and Conda are trying to do the same thing - creating a hermetic environment. Bazel is not a wrapper for Conda. Its one-ring-to-rule-them-all nature would like to replace it. So if you want to compile targets with different conda environments, nature separates things. The same is for Bazel.

All in all, using --python_top and having multiple runs (stuff that can be managed properly with configurations in .bazelrc) is not too bad. My only concern is that --python_top in the documentation page is mentioned only as a workaround for a bug related to python versions and wrong python runtime picked up (https://bazel.build/reference/be/python#py_binary.python_version)
And I don't want that if this is fixed, the --python_top starts a deprecation life cycle.