Questions around the `bind` used for scala imports

[Shastick]

So, here I come with a specific question that was part of my exploration, as described in https://github.com/johnynek/bazel-deps/issues/291.

The Question

• Can we control how the binding of dependency targets is done, either via the dependencies.yml file or by some arguments passed to bazel-deps?
• could we disable binding entirely (via config/flags)? It seem the usage of bind is not recommended. Is there an important reason bazel-deps relies on it?

As I've found a satisfactory work around for this it's certainly not urgent, I'm mostly asking out of curiosity.

Context

I'm using an aspect to walk my dependencies and collect their maven coordinates. This works fine for java dependencies, but does not for scala.

This seems to be due to the fact that for scala, libraries point to the file filegroup, instead of the jar java_import, which contains the tag.

Fixes for this are reasonably easy: I can patch the workspace.bzl file to include the tag in the filegroup(*), or just replace the binding from jar:file to jar:jar. Both approaches work and result in successful builds.

For the sake of example, here is the entry for json4s-core in the dependencies listed in list_dependencies() of the workspace.bzl file:

{
  "artifact": "org.json4s:json4s-core_2.12:3.6.7",
  "lang": "scala",
  "sha1": "...",
  "sha256": "...",
  "repository": "...",
  "url": "...,
  "source": {
    "sha1": "...",
    "sha256": "...",
    "repository": "...",
    "url": "..."
  },
  "name": "org_json4s_json4s_core_2_12",
  "actual": "@org_json4s_json4s_core_2_12//jar:file",
  "bind": "jar/org/json4s/json4s_core_2_12"
}

The actual field binds the external:jar/... to @org_json4s_json4s_core_2_12//jar:file. As mentioned, replacing jar:file with jar:jar gets me what I want.

Thanks again for your work and attention!

(*) that approach does not work in the end: I need to point to a rule that provides a JavaInfo, and filegroup falls short of this.

[ianoc]

Sorry about the late reply here, don't think I ever got notified about this for some reason.

There's a few different bits here:

Its not jar/jar and is jar/file since iirc macros won't work in jars if its jar/jar. Since those need different code availability semantics.

Bind being not recommended was and generally still is controversial outside google iirc. There's a long issue/discussion on the bazel GitHub somewhere.The not using bind has long stalled I believe. rules_scala itself uses them heavily. Some use cases could in theory be replaced by toolchains but not all easily, some of those didn't work properly (host vs target platform stuff).

You can expand where the tags are and this should be fine, also you can supply your own methods to take the workspace.bzl files and reify them how you see fit. both workspace.bzl and the target_file.bzl are largely built around methods that are there, you can substitute your own in here I believe without it being too much of a problem.

[Shastick]

Thanks for the reply.

Its not jar/jar and is jar/file since iirc macros won't work in jars if its jar/jar. Since those need different code availability semantics.

Indeed, that is an important point to keep in mind.