Can module extension depend on a target (as a tool)?

[cbullo]

Looking at bzlmod/utils/librarian/librarian.bzl in examples repo, I can see that it conveniently gets a path to librarian.py (or .cmd) file that lives in the root and executes it.

But what if the (binary) file that I want to execute is not a simple .py (or .sh, or pre-built binary), but rather something that needs to be built, say C++ or Rust code. Ideally, it should be built by bazel before (!) module_extension runs.

I imagine this is not possible (currently), but I'm wondering how, conceptually, this could be solved. Would Bazel have to repeat phases iteratively to achieve that?

[meteorcloudy]

I think in theory this could be possible if the module extension isn't required for building the tool. But to properly detect such potential cycle dependency require a lot of effort in Bazel.

/cc @Wyverald Is my understanding correct? Or there are bigger blockers I'm missing.

[cbullo]

Thank you! That's pretty much the answer I expected to get. The use cases here would be rather niche, so I don't expect to see any interest in developing this.
My use case is a pure research. I'm playing with an idea of extracting dependencies from the 'source' files and generating bazel dependencies from them using only module extensions/repo rules. But to do this I need various, file type specific 'preprocessors' which can look at the source files and tell me what dependencies they have. Some of these preprocessors I need to build from source.
Hence my question.

[meteorcloudy]

Thanks! Yes, we are aware of such valid use cases, but still unclear whether we'll invest how much effort to make it work.

[Wyverald]

there are indeed bigger blockers -- currently, Bazel's loading and analysis phases cannot use results from the execution phase. Changing this would require a rather big architectural earthquake -- for example, bazel query would now potentially need to run an action, which means remote execution needs to be set up, etc.