Allow rulesets to integrate with bazel mod tidy to update lock files.

[shs96c]

Description of the feature request:

Most rulesets that integrate with third-party deps maintain their own lock files. These are read at build-time to generate various workspaces (eg. @maven is commonly created when using rules_jvm_external). At present, the way to fully update a module file to incorporate changes made in these definitions is:

1. Update the source of truth for the third party deps
2. Run ruleset-specific tooling to update the lock file
3. Run bazel mod tidy

It would be a smoother user experience if there was some way to tell Bazel that the second step could be performed using some target that can be bazel run. Could we extend module_context.extension_metadata to include a list of runnable targets, env vars, and possibly command line flags that could be called to update deps?

Which category does this issue belong to?

No response

What underlying problem are you trying to solve with this feature?

Simplifying developer workflows when updating third party dependencies. This is handled differently by every ruleset, and makes working in a polyglot repo hard, especially for users who seldom update dependencies.

Which operating system are you running Bazel on?

No response

What is the output of bazel info release?

No response

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

Have you found anything relevant by searching the web?

There is a proposal for the module lock file to have persistent storage: #24777. It is possible that as part of this, we could use the bazel lock file to store resolution results (or similar) for third party dependencies, but to do so, we'd still need to use bazel run.

As an example, in rules_jvm_external the resolution is done using a target that can be executed via bazel run, as the target has its own dependencies, is too large to include as a binary, and requires the use of the hermetic java toolchain provided by rules_java. We don't want to prebuild the resolver since that would require additional infrastructure for us to manage release and would complicate developing the ruleset.

Any other information, logs, or outputs that you want to share?

Discussion on the Bazel Slack channel

[fmeum]

I know it's not going to happen soon, but this should be counted as an argument in favor of allowing repo rules and module extensions to execute build targets, not just source files.