rules_scala icon indicating copy to clipboard operation
rules_scala copied to clipboard

Apparently unresolvable issue using `minimal_direct_source_deps` toolchain

Open macripps opened this issue 3 years ago • 1 comments
trafficstars

I was attempting to see if our Scala code could build under a stricter toolchain as we are currently plagued by over-broad dependency lists and reliance on transitive targets pulling in dependencies.

However, a very minimal case seems to be unresolvable with this toolchain, and I was wondering if I was simply using it wrongly?

MyModule.scala

package mypackage

import com.twitter.inject.TwitterModule

object MyModule extends TwitterModule {}

BUILD

scala_library(
    name = "mypackage",
    srcs = [
        "MyModule.scala",
    ],
    deps = [
        # should I be adding "@maven//:org_scala_lang_scala_library" here?
        "@maven//:com_twitter_inject_core_2_12",
    ]
)

Building this target reports the following error:

ERROR: [elided]src/scala/mypackage/BUILD:1:14: scala //src/scala/mypackage:mypackage failed: (Exit 1): scalac failed: error executing command bazel-out/darwin-opt-exec-2B5CBBC6/bin/external/io_bazel_rules_scala/src/java/io/bazel/rulesscala/scalac/scalac @bazel-out/darwin-fastbuild/bin/src/scala/mypackage/mypackage_scalac_worker_input
src/scala/mypackage/MyModule.scala:5: error: Symbol 'type com.twitter.util.logging.Logging' is missing from the classpath.
This symbol is required by 'trait com.twitter.inject.Logging'.
Make sure that type Logging is in your classpath and check for conflicting dependencies with `-Ylog-classpath`.
A full rebuild may help if 'Logging.class' was compiled against an incompatible version of com.twitter.util.logging.
object MyModule extends TwitterModule {}
                        ^
one error found
Build failed

The class com.twitter.util.logging.Logging is found in com.twitter:util-slf4j-api_2.12, but after adding the appropriate target to deps:

    deps = [
        "@maven//:com_twitter_inject_core_2_12",
        "@maven//:com_twitter_util_slf4j_api_2_12",
    ]

however, I get this error:

ERROR: [elided]/src/scala/mypackage/BUILD:1:14: scala //src/scala/mypackage:mypackage failed: (Exit 1): scalac failed: error executing command bazel-out/darwin-opt-exec-2B5CBBC6/bin/external/io_bazel_rules_scala/src/java/io/bazel/rulesscala/scalac/scalac @bazel-out/darwin-fastbuild/bin/src/scala/mypackage/mypackage_scalac_worker_input
error: Target '@maven//:com_twitter_util_slf4j_api_2_12' is specified as a dependency to //src/scala/mypackage:mypackage but isn't used, please remove it from the deps.
You can use the following buildozer command:
buildozer 'remove deps @maven//:com_twitter_util_slf4j_api_2_12' //src/scala/mypackage:mypackage
one error found
Build failed

All of these third party dependencies are correctly configured in my maven_install.json file as they can be found by performing a somepath query.

./bazel query 'somepath(//src/scala/mypackage:mypackage,@maven//:com_twitter_util_slf4j_api_2_12)'
//src/scala/mypackage:mypackage
@maven//:com_twitter_inject_core_2_12
@maven//:com_twitter_inject_slf4j_2_12
@maven//:com_twitter_util_slf4j_api_2_12

So will I ever be able to use the minimal_direct_source_deps toolchain? Is there a way to work around this?

macripps avatar Mar 15 '22 17:03 macripps

This is a know problem with the current AST dependency analyzer - it only looks at the ast of target code, but Scala compiler needs more information while compiling (I guess in your case it needs base class from another target, which is not directly mentioned in your code). One solution can be to improve analyzer so it reports type hierarchies as direct deps, but this approach introduces other problem: if base type in the dependency is changed with unknown types to dependents, all of them will need to be updated. Such behavior may be problematic for cross repo development. I have achieved acceptable results on large repos by using plus-one dependency mode with combination of unused_dependency_checker_ignored_targets (on the analyzed target) and sometimes with exports of additional deps on the dependency target. This is still experimental feature, and any help improving it (from ideas to implementation) is very welcome.

liucijus avatar Mar 15 '22 18:03 liucijus