update to `rules_jvm_external` to 6.4 breaks build with `Failed to load Starlark extension '@@bazel_features//:features.bzl'`

[hb-man]

can be reproduced on this project/branch

https://github.com/JetBrains/hirschgarten/pull/68

full error message:

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.
 - @@bazel_features
This could either mean you have to add the '@@bazel_features' 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.
Computing main repo mapping:
ERROR: Error computing the main repository mapping: cycles detected during computation of main repo mapping

i tried fixing it by adding explicit dependency to bazel_features - but than i get another error:

ERROR: Failed to load Starlark extension '@@bazel_features_version//:version.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.
 - @@bazel_features_version
This could either mean you have to add the '@@bazel_features_version' 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

Though, if I add bazel_features depndency explicit, but WORKSPACE-style - it starts to work. This might be a bug in bazel features so I'll file it there.

[shs96c]

We load bazel_features from our MODULE.bazel here, and I think that's all we need to do in order to start using it via bzlmod. I believe that the @@bazel_features_version workspace contains the value of the current version bazel number, so I think this may be an issue with bazel_features and not us.

[gergelyfabian]

I'm not sure this is bzlmod specific. I encountered this issue when upgrading rules_jvm_external to 6.4 in a traditional WORKSPACE project.

[daniel-b2c2]

@shs96c, To clarify, is the suggested solution that we add

bazel_dep(
    name = "bazel_features",
    version = "1.17.0",
)

in our own projects, in order to fix the cyclic dependency issue? Strange since we don't specifically use bazel_features it should just be picked up transitively

To be clear, this was all working before and broke after the upgrade of rules_jvm_external from 6.2 to 6.4

@fmeum has suggested this as the possible cause: https://github.com/bazelbuild/rules_java/issues/225#issuecomment-2388494967

Sorry if its a red-herring, I am a basic user of bazel, I'm still trying to understand bazel/modules, but it does look and feel like a regression/bug, but I'm still not clear which project has introduced it.

[fmeum]

You could also call rules_jvm_external's dependency macro in your WORKSPACE file. The workaround is only needed because rules_sonatype is a WORKSPACE dep, these issues can't arise with pure Bzlmod.

[gergelyfabian]

Here is a reproduction with a simple WORKSPACE repo:

https://github.com/gergelyfabian/bazel-scala-example/tree/rules_jvm_external_6.4

I don't see rules_sonatype used here, but maybe I just missed it (checked external/ in the cache).

I also call the external dependency macro from rules_jvm_external (on the branch).

In addition I tried (did not commit that) explicitly calling bazel_features at the top of my WORKSPACE file, but it still has a cycle, even though with a different error:

$ bazel build //...
INFO: Invocation ID: cb5b147f-199c-4c49-9e79-3d71660fa98b
ERROR: Failed to load Starlark extension '@@bazel_features_version//:version.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.
 - @@bazel_features_version
This could either mean you have to add the '@@bazel_features_version' 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

[hb-man]

So, the issue was solved for us after switching rules_sonatype to bzlmod dep instead of WORKSPACE one. I'm closing the issue, since the diagnostics about rules_sonatype were right. @gergelyfabian I would assume you also have some dependency incorrectly configured (not rules_sonatype probably, but a different one) which also raises the same error and also do more diagnostics or open a separate issue.

I'm closing this one @fmeum thanks a lot for helping with this

[agluszak]

So, the issue was solved for us after switching rules_sonatype to bzlmod dep instead of WORKSPACE one.

To be precise: to bzlmod (WIP) version of rules_scala: https://github.com/mbland/rules_scala/tree/bzlmod

[gergelyfabian]

So, the issue was solved for us after switching rules_sonatype to bzlmod dep instead of WORKSPACE one.

To be precise: to bzlmod (WIP) version of rules_scala: https://github.com/mbland/rules_scala/tree/bzlmod

Thanks. That's a very important detail. We did not switch to bzlmod mainly due to rules_scala not having it available.

[gergelyfabian]

For me the solution was to add in my WORKSPACE (at the top):

http_archive(
    name = "bazel_features",
    sha256 = "bdc12fcbe6076180d835c9dd5b3685d509966191760a0eb10b276025fcb76158",
    strip_prefix = "bazel_features-1.17.0",
    url = "https://github.com/bazel-contrib/bazel_features/releases/download/v1.17.0/bazel_features-v1.17.0.tar.gz",
)

load("@bazel_features//:deps.bzl", "bazel_features_deps")

bazel_features_deps()

This is kind of a parallel of what rules_jvm_external defines.

But, to take it even further...

I could move that stanza down to where rules_jvm_external is defined, so this is not a conflict with any other dependency in my project. Finally I managed to only reorganize the WORKSPACE inclusions so that the error disappears:

This works:

load("@rules_jvm_external//:repositories.bzl", "rules_jvm_external_deps")

rules_jvm_external_deps()

load("@rules_jvm_external//:setup.bzl", "rules_jvm_external_setup")

rules_jvm_external_setup()

load("@rules_jvm_external//:defs.bzl", "maven_install")
load("@rules_jvm_external//:specs.bzl", "maven")
load("@rules_jvm_external_deps//:defs.bzl", rules_jvm_external_deps_pinned_maven_install = "pinned_maven_install")

rules_jvm_external_deps_pinned_maven_install()

This doesn't work:

load("@rules_jvm_external//:defs.bzl", "maven_install")
load("@rules_jvm_external//:repositories.bzl", "rules_jvm_external_deps")

rules_jvm_external_deps()

load("@rules_jvm_external//:setup.bzl", "rules_jvm_external_setup")

rules_jvm_external_setup()

load("@rules_jvm_external//:specs.bzl", "maven")
load("@rules_jvm_external_deps//:defs.bzl", rules_jvm_external_deps_pinned_maven_install = "pinned_maven_install")

So I had maven_install's definition loaded just too early and this caused the cycle error.

When I check the docs I see that they do the setup in the proper order, I must have had this for longer in the improper order... (probably did not pay enough attention somewhere around upgrading to 4.1).

[gergelyfabian]

And, in my previous attempts to work this around I just missed these lines just after importing bazel_features:

load("@bazel_features//:deps.bzl", "bazel_features_deps")

bazel_features_deps()

I guess it could be the same issue for the reporter:

i tried fixing it by adding explicit dependency to bazel_features - but than i get another error: