This is about support for the subcommand currently known as bzlmod query. It should be able to print out the dependency graph, show some path from one module to a (transitive) dependency, among other things.

To achieve this, we need to store more information in the lockfile (essentially, the entire dependency graph, even pre-selection).

We should collect the bazel_compatibility declarations of all modules in the dep graph, compute the intersection, and output that into the WORKSPACE file (or if we're definitely version-locking bzlmod and Bazel, fail outright).

• Ability to "call" module rules in MODULE.bazel
• Loading and executing the module_rule_exports file of any referenced Bazel modules, after bazel_deps are resolved (i.e. post-discovery-and-selection)
• Running the resolve function with collected tags
• Implementation of the bfs builtin
• Implementation of the attr module
• Implementation of the ModuleRuleContext object (and potentially a shim for repository_ctx)
• Writing ResolveResults to WORKSPACE and the lock file
• Being able to fetch repos resulting from module rules, by loading necessary info from the lock file and running the fetch function

No checkboxes here, since all of this need to be done at once for module rules to have any semblance of working.

Either as an override, or as a single-module registry.

• support for these attrs on module
• support for these attrs in module rules

https://github.com/golang/go/wiki/CodeReviewComments#imports

• Patches in index registries (source.json)
• Patches in overrides (archive, git, single_version)
• Fuzzy matching

The plumbing of patching information is already done (patch files, patch_strip, etc). The work left is to actually do the patching (mainly in the Archive fetcher; after Git support is in, in the Git fetcher too).

This entails throwing an error at selection time if different versions of a module were discovered, but they have different compatibility_levels.

• bzlmod add [email protected]
• bzlmod add -f [email protected]
• bzlmod add X
• bzlmod add --upgrade_all
• bzlmod remove X

This involves programmatically modifying the MODULE.bazel file, so there could be minor challenges (for example, a user can technically use list comprehensions in MODULE.bazel)

Currently we correctly parse and store this override, but don't use it properly. Changes need to be made in Selection.

Right now bzlmod doesn't deal with concurrent calls very well. All sorts of race conditions could happen if bzlmod resolve and bzlmod fetch are called concurrently, whether inside the same workspace or across different workspaces.

Right now, for the Archive fetcher, strip_prefix is implemented using strings.TrimPrefix. This has two problems:

• It strips the prefix "foo/bar" from the path "foo/bar_license", resulting in a file called "_license". Stripping should work on a path segment level.
• It doesn't do anything when the path doesn't begin with the prefix (ie. if the path is "foo/baz", and strip_prefix is "foo/bar", then the file "foo/baz" remains in the extracted files). The correct behavior is to ignore any such files.

Should be an easy fix; during discovery, instead of using starlark.ExecFile, we should manually parse the file and inspect the AST and throw an error if control flow statements or function definitions exist.

Reintroduce dev_dependency to bazel_dep.

We removed it because of potential BUILD breaks in situations like bazelbuild/bazel#12835. However, not having dev dependencies means that the dependency graph could be cluttered in an unbounded manner. For example, most rulesets depend on bazel_skylib, which uses rules_pkg to manage releases. Without dev dependencies, this means that most Bazel projects would depend on bazel_skylib -> rules_pkg -> rules_python -> {insert crapton of deps here}.

• git_override
• single module registries

Both need the Git fetcher to be implemented first.