Late loading of dependencies leads to cycle error

[Xjs]

Description of the problem / feature request:

Many of our projects share a similar setup of Go applications which are built into Docker containers. To that end, we use with some joy https://github.com/bazelbuild/rules_go and https://github.com/bazelbuild/rules_docker.

We are trying to simplify the Bazel boilerplate required for projects, attempting to consolidate all Bazel rule dependencies and some custom code into a common repository that can be loaded by projects with a single command.

While doing this, the interaction of rules_go and rules_docker in combination with loading dependencies in a workspace rule causes Bazel to detect a workspace cycle. I believe the cause of this is the behaviour of load(). However, if you think this could easier be worked around by the maintainers of one of those repositories or even by myself, please do let me know.

The bug in question is: the load() call in https://github.com/Xjs/bazel-debug-rules-go/blob/demonstrate-workspace-hack-loop/go/def.bzl#L8 appears to reference dependencies in a way that they already have to be declared in the workspace when load() is executed.

I would expect that either load() does not require any declared dependencies, and those would only be required at the time the load()ed rule is called (which would be https://github.com/Xjs/bazel-debug-rules-go/blob/demonstrate-workspace-hack-loop/go/def.bzl#L16)

Alternatively I would expect there being a way to dynamically only load() @io_bazel_rules_docker//go:image.bzl's repositories rule after declaring the required dependencies. However, Bazel informs me that load() can only occur at the top level of a module.

Again, I'm not entirely sure if this is a Bazel bug or expected behaviour -- if the latter, I would be happy for advice on how to work around it while still being able to maintain a repository that declares all dependencies (rules_go, rules_docker, some unrelated rule repositories that do not cause problems here) with a single workspace rule.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Clone the https://github.com/Xjs/bazel-debug-rules-go repository.

Check out nonworking-demo and try to bazel build main.

Observe the error message recording a cycle.

Remove https://github.com/Xjs/bazel-debug-rules-go/blob/demonstrate-workspace-hack-loop/go/def.bzl#L8 to have a working build.

What operating system are you running Bazel on?

Windows 10 Insider Preview (Version 2004, OS Build 20152.1000).

What's the output of bazel info release?

release 3.3.0

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

Actually, I would expect https://github.com/Xjs/bazel-debug-rules-go/tree/wanted-state to work already, but trying to build https://github.com/Xjs/bazel-debug-rules-go/tree/nonworking-demo based on this state of the repository fails with missing dependencies already, which I then predeclared until I reached the aforementioned cycle.

[ah-quant]

See also #1943 (comment)

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!