Dependency cycle in @@local_config_platform (somehow caused by publish_binary.bzl)

[jmillikin]

I'm not sure exactly what's going on here, but something about the load() order in rules_dotnet is causing Bazel to report a dependency cycle when I try to build even basic C# targets:

$ bazel build //experimental/dotnet-helloworld:hello
INFO: Invocation ID: 770af402-9842-4034-9c58-64b284ab504a
ERROR: Failed to load Starlark extension '@@local_config_platform//:constraints.bzl'.
Cycle in the workspace file detected. This indicates that a repository is used prior to being defined.
The following chain of repository dependencies lead to the missing definition.
 - @@local_config_platform
This could either mean you have to add the '@@local_config_platform' repository with a statement like `http_archive` in your WORKSPACE file (note that transitive dependencies are not added automatically), or move an existing definition earlier in your WORKSPACE file.
ERROR: Error computing the main repository mapping: cycles detected during computation of main repo mapping

After some trial and error, I found that any attempt to load("@local_config_platform//:constraints.bzl", ...) from within the root workspace will fail with the above error. The docs on local_config_platform are not sufficient for me to determine whether this is a bug in Bazel.

The exact path to get to that line is something like:

# dotnet/private/sdk/apphost_packs/dotnet.apphost_packs.bzl
load("@rules_dotnet//dotnet:defs.bzl", "nuget_repo")

# dotnet/defs.bzl
load(
    "//dotnet/private/rules/publish_binary:publish_binary.bzl",
    _publish_binary = "publish_binary",
)

# dotnet/private/rules/publish_binary/publish_binary.bzl
load("//dotnet/private/transitions:tfm_transition.bzl", "tfm_transition")

# dotnet/private/transitions/tfm_transition.bzl
load("@local_config_platform//:constraints.bzl", "HOST_CONSTRAINTS")

As a workaround, changing the files dotnet.apphost_packs.bzl, dotnet.targeting_packs.bzl, and dotnet.runtime_packs.bzl to load the nuget_repo rule directly allows the build to succeed for me:

diff --git a/dotnet/private/sdk/apphost_packs/dotnet.apphost_packs.bzl b/dotnet/private/sdk/apphost_packs/dotnet.apphost_packs.bzl
index 00b9ada..3db5a31 100644
--- a/dotnet/private/sdk/apphost_packs/dotnet.apphost_packs.bzl
+++ b/dotnet/private/sdk/apphost_packs/dotnet.apphost_packs.bzl
@@ -1,6 +1,6 @@
 "GENERATED"
 
-load("@rules_dotnet//dotnet:defs.bzl", "nuget_repo")
+load("@rules_dotnet//dotnet/private/rules/nuget:nuget_repo.bzl", "nuget_repo")
 
 def apphost_packs():
     "apphost_packs"
diff --git a/dotnet/private/sdk/runtime_packs/dotnet.runtime_packs.bzl b/dotnet/private/sdk/runtime_packs/dotnet.runtime_packs.bzl
index 70c45ca..41e4f48 100644
--- a/dotnet/private/sdk/runtime_packs/dotnet.runtime_packs.bzl
+++ b/dotnet/private/sdk/runtime_packs/dotnet.runtime_packs.bzl
@@ -1,6 +1,6 @@
 "GENERATED"
 
-load("@rules_dotnet//dotnet:defs.bzl", "nuget_repo")
+load("@rules_dotnet//dotnet/private/rules/nuget:nuget_repo.bzl", "nuget_repo")
 
 def runtime_packs():
     "runtime_packs"
diff --git a/dotnet/private/sdk/targeting_packs/dotnet.targeting_packs.bzl b/dotnet/private/sdk/targeting_packs/dotnet.targeting_packs.bzl
index 2a1c318..e7c53c1 100644
--- a/dotnet/private/sdk/targeting_packs/dotnet.targeting_packs.bzl
+++ b/dotnet/private/sdk/targeting_packs/dotnet.targeting_packs.bzl
@@ -1,6 +1,6 @@
 "GENERATED"
 
-load("@rules_dotnet//dotnet:defs.bzl", "nuget_repo")
+load("@rules_dotnet//dotnet/private/rules/nuget:nuget_repo.bzl", "nuget_repo")
 
 def targeting_packs():
     "targeting_packs"

Bazel version: v7.1.2
Platform: Linux amd64 (but I suspect this isn't relevant)

[purkhusid]

Are you using bzlmod or WORKSPACE?

[jmillikin]

I'm using WORKSPACE, and plan to migrate to bzlmod in Bazel v7.2 (which contains a fix for bazelbuild/bazel#17880)

[purkhusid]

Ok, I dropped WORKSPACE support recently to lower the maintenance burden of the rules. I'm inclined to close the issue since you can use your patch as a workaround until you migrate to bzlmod, do you think this requires more investigation?

[jmillikin]

That sounds reasonable. I'm fine with closing this issue if you think the problem is specific to WORKSPACE mode.

[purkhusid]

I did not manage to replicate this when using bzlmod so I'll close this. Feel free to re-open if you still have this issue once you've migrated to bzlmod.