Obtaining the maven coordinates of dependencies managed via bazel-deps from an aspect

Shastick commented 4 years ago

Good day,

First, let me apologise in advance if this question ends up being more Bazel specific rather than bazel-deps specific: I've only recently started learning it, and while I feel like this is something related to bazel-deps I may be wrong. Please close the issue if this is so.

Secondly, thank you for sharing this tool with the community: I'm happy to say it is helping us in a meaningful way.

The Question

Using an aspect I'm trying to obtain the maven coordinates of dependencies that are imported/managed with bazel-deps. This seems to work well for java dependencies (although I'm not sure to understand why), but fails for scala.

Looking at the bazel-<project>/external/@<dep>/jar/BUILD file, I can see that indeed, the tags attribute is set to what I need (here, as an example, let's use json4s-core):


package(default_visibility = ['//visibility:public'])
java_import(
    name = 'jar',
    tags = ['maven_coordinates=org.json4s:json4s-core_2.12:3.6.7'],
    jars = ['org_json4s_json4s_core_2_12.jar'],
    srcjar = ":org_json4s_json4s_core_2_12-sources.jar",
)
filegroup(
    name = 'file',
    srcs = [
        'org_json4s_json4s_core_2_12.jar',
        'org_json4s_json4s_core_2_12-sources.jar'
    ],
    visibility = ['//visibility:public']
)

The problem, as I perceive it, is that the BUILD files generated from our dependencies.yml file references the filegroup above, not the java_import rule, preventing me from accessing the tags attribute in java_import.

Funnily, this does not concern java dependencies, where the relevant tags are correctly being collected.

Could it be because for scala, in the generated BUILD file, we rely on scala_import, but for java we rely on java_library? If so, is there a work-around?

Attempts at a solution

Having grepped around in the bazel-deps sources, I noticed that https://github.com/johnynek/bazel-deps/blob/48fdf7f8bcf3aadfa07f9f7e6f0c9f4247cb0f58/src/scala/com/github/johnynek/bazel_deps/templates/external_workspace_backend.bzl contains a template for issuing scala_library rules if the kind of the dependency is library, though I've found no way to mark a dependency as a "library" rather than an import.

The final word

Anyway, I'm not sure I grasp every layer in the process of dependencies.yml -> workspace + BUILD file generation -> import of external repositories -> usage of external repositories, but that's another story entirely: things work fine for building, that's a start :)

Many thanks again for your work.

Kindly

Shastick commented 4 years ago

So, after looking at this with a fresh pair of eyes, it looks like my ignorance is to blame, not bazel deps :)

Long story short:

I got confused by the binding that happens between @<dep> and //external (which also binds
resolving the correct target (ie, the jar instead of the filegroup) gets me a step closer to what I want. I'm not there yet, but that's a limit of my Bazel knowledge.

Happy coding!

johnynek commented 4 years ago

glad it is useful and you figured it out!

I'm confused why json4s is considered a java dependency though, you may want to explicitly add it to your yaml file. Some things can work marginally better with scala_import (e.g. if there are macros involved).

Shastick commented 4 years ago

So, to clarify (just in case I need to open another issue for a – likely – upcoming question):

the BUILD files generated by bazel-deps in the WORKSPACE where we use the dependencies correctly contain a scala_import, as the doc specifies.

That scala_import itself references the //external:jar/... that points to the filegroup in the example above. The BUILD file in the sample is the one generated by the macro in workspace.bzl.

Thanks for the reply!

bazeltools / bazel-deps