bazel: Strict deps infraction passes when it should fail- regression in 0.12.0-RC1
Description of the problem / feature request:
Bazel 0.12.0-RC1 (built from https://github.com/bazelbuild/bazel/commit/b33e5afa313322a7048044c44d854cbb666b988e) passes a strict deps infraction using rules_scala scala_import when it correctly fails it on 0.11.1
BUILD.bazel
:
package(default_visibility = ["//visibility:public"])
load(
"@io_bazel_rules_scala//scala:scala_import.bzl",
"scala_import",
)
java_library(
name = "leaf",
srcs = ["Leaf.java"],
deps = [":scala_import_transitive"],
)
#failure only on 0.11.1 bazel
java_import(
name = "scala_import_transitive",
jars = [],
deps = [
":logback_scala_import",
],
)
scala_import(
name = "logback_scala_import",
jars = [
"logback-classic-1.1.11.jar",
],
)
#failure on both 0.11.1 bazel and 0.12.0-rc1
java_import(
name = "java_import_transitive",
jars = [],
deps = [":logback_java_import"],
)
java_import(
name = "logback_java_import",
jars = [
"logback-classic-1.1.11.jar",
],
)
Bugs: what’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
run bazel build on this [repo](repro: https://github.com/ittaiz/strict-deps-false-positive/tree/master ) with 0.11.1 and see it fail, then run it with the above bazel binary and see it pass
What operating system are you running Bazel on?
mac os
Any other information, logs, or outputs that you want to share?
I haven’t been able to drill down and figure out if this is a scala_import issue or a java-skylark issue. Might be relevant to add I’m also witnessing false negative issues with strict deps where it prints out warnings for direct dependencies. Still working on an isolated repro for that
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 18 (18 by maintainers)
Commits related to this issue
- Emit SJD errors even if we don't know the label of a dependency Fixes bazelbuild/bazel#4846 PiperOrigin-RevId: 189123353 — committed to bazelbuild/bazel by cushon 6 years ago
- Emit SJD errors even if we don't know the label of a dependency Fixes bazelbuild/bazel#4846 PiperOrigin-RevId: 189123353 — committed to bazelbuild/bazel by cushon 6 years ago
- Emit SJD errors even if we don't know the label of a dependency Fixes bazelbuild/bazel#4846 PiperOrigin-RevId: 189123353 — committed to bazelbuild/bazel by cushon 6 years ago
- Emit SJD errors even if we don't know the label of a dependency Fixes bazelbuild/bazel#4846 PiperOrigin-RevId: 189123353 — committed to luca-digrazia/DatasetCommitsDiffSearch by deleted user 2 years ago
I’m not very knowledgeable about this part of Bazel, but I looked at the involved changes and it seems like this is impossible to rollback. Now, what do we do with Bazel 0.12.0?
@ittaiz I totally agree that this should have been discussed in the open. It’s really not OK to break the work that our contributors do for Bazel. 😦
@tomlu I think your answer is not really sufficient. You can’t just break people’s work, then not even apologize and then say “Oh, I don’t have an opinion except that reverting my work is not an option”. You’re on the Bazel team, too - can you please follow up here and work with @ittaiz and @hsyed to find a good solution that works for everyone?
(FYI @ulfjack @davidstanke)