Accessibility of runtime_deps and transitive deps

[dhalperi]

Hey,

We're (cc: @arifogel) having a heck of a time trying to understand how the IntelliJ plugin handles transitive deps. The issue we're having is that only direct compile dependencies (hjars for bazel-built or maven jars) are in External Libraries. When we're debugging, we're unable to see source code for or set breakpoints in the runtime_deps or the dependencies of our direct compile dependencies.

Adding them to the bazelproject, e.g., targets: @external_project//some/java_library does not make that library indexable.

Is there a different recommended approach to solve this problem?

Thanks!

[brendandouglas]

We intentionally exclude transitive deps from the project for performance reasons -- only deps (both direct and transitive) actually required to resolve the source code are added to the project libraries. One exception to this is that for locally modified files we include all direct deps if "Blaze > Sync > Expand sync to working set" is checked. So you won't be able to debug into transitive deps, unless they're required to resolve some source file in your project, or are listed as a direct dep of a target with modified source files, and that option above is enabled. We never treat external libraries as 'source' code of the project for these purposes.

…

On Wed, May 13, 2020 at 5:58 PM Dan Halperin ***@***.***> wrote: Hey, We're (cc: @arifogel <https://github.com/arifogel>) having a heck of a time trying to understand how the IntelliJ plugin handles transitive deps. The issue we're having is that only direct compile dependencies (hjars for bazel-built or maven jars) are in External Libraries. When we're debugging, we're unable to see source code for or set breakpoints in the runtime_deps or the dependencies of our direct compile dependencies. Adding them to the bazelproject, e.g., targets: @external_project//some/java_library does not make that library indexable. Is there a different recommended approach to solve this problem? Thanks! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1825>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE3KDEIZE4RIEPHO7V7UV4TRRMJZTANCNFSM4NAEWMOA> .

[dhalperi]

Thanks for the info!

I'm guessing this works for Blaze - there's a monorepo, no such thing as external deps really, since folks use copybara instead.

Seems an ill fit for Bazel where external projects is a recommended way to operate. (But I am generally aware Bazel support is not much of a concern for this team.)

[brendandouglas]

You're right, it's not an ideal set of features for Bazel. Internally, there's no concept of an external workspace, it's simply not supported by Blaze. I would personally enjoy spending time restructuring the plugin to better support Bazel (there's so much potential there), but we don't have the bandwidth unfortunately. Note we have the same debugging issue internally (though it doesn't come up often) -- we don't attach transitive deps to the project, so you can't step into that code when debugging. One workaround would be to add those deps to the target you're debugging (with 'expand to working set' enabled).

…

On Fri, May 15, 2020 at 12:16 PM Dan Halperin ***@***.***> wrote: Thanks for the info! I'm guessing this works for Blaze - there's a monorepo, no such thing as external deps really, since folks use copybara instead. Seems an ill fit for Bazel where external projects is a recommended way to operate. (But I am generally aware Bazel support is not much of a concern for this team.) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1825 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE3KDEKCMPF6O2VZJC36RSLRRVTEXANCNFSM4NAEWMOA> .

[ittaiz]

I want to emphasize Brendan’s point- I think this specific issue is not related to blaze/bazel as the issue isn’t external workspaces but debugging transitive deps.
Brendan- there isn’t a setting or something to allow loading all transitive deps as external libraries? Sounds like this can be an easy fix which could be only available to Bazel.
Wdyt?

[dhalperi]

@ittaiz I might take a look at implementing such a feature, if at least to see whether it might be worth forking.

[brendandouglas]

We could add that feature to the plugin -- JavaWorkspaceImport / JavaSourceFilter is the code which limits which deps are added as libraries.

[sgowroji]

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.

[dhalperi]

I don't think anything has changed with respect to why this is a big problem.

[dhalperi]

Please reopen if you’d like to discuss

I don't seem to have this power, FYI.