Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IJ selecting the incorrect Bazel target when debugging a Py test under transition #7196

Open
andponlin-canva opened this issue Dec 18, 2024 · 1 comment
Assignees
Labels
awaiting-maintainer Awaiting review from Bazel team on issues product: IntelliJ IntelliJ plugin type: bug

Comments

@andponlin-canva
Copy link
Contributor

andponlin-canva commented Dec 18, 2024

Description of the bug:

See PR 7198.

Can't launch the debugger from the context menu

In a specific project that uses a pinned Python interpreter (internally using a transition) we see that the following query;

bazel query "same_pkg_direct_rdeps(//...)" --output=label_kind

...brings up...

py_test rule //blah:_test
_transition_py_test rule //blah:test

This query is done by the IJ plugin to understand the Rules in the repo.

Unfortunately when the user chooses to debug a Python file, the selected py_test target is :_test and so the debugger fails to launch because the :_test target is not a real one and you can't run it. A work-around is to keep going to the "Edit Configurations..." manually and modifying the label. This is tedious and difficult to communicate.

The problem can be solved by making the IJ plugin choose the correct one and observe that _transition_py_test is actually a py_test.

Can't find sources for the right target

A further problem comes up around mapping the //blah:test back to the source in order to create a reverse mapping in the plugin from the source to the _transition_pt_test target. This creates a situation where it appears that //blah:test has no sources. Because it has no sources, it is never considered to be the target to debug for a given source file when the user opens the context-menu on the source file.

I suspect that this happens because under Bazel 7 there is a mix of PyInfo from Bazel and PyInfo from rules_python in play and the PyInfo used differs between the :_test and :test targets. The templated python_info.bzl is incorrectly assuming that PyInfo from rules_python is only coming into play on Bazel >8. Because the Python specific logic in intellij_info_impl.bzl is unable to find the right PyInfo on the _transition_py_test kind target, it never performs analysis on its sources.

Which category does this issue belong to?

Intellij

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Please see the comment below for an example project which demonstrates the issue.

Which Intellij IDE are you using? Please provide the specific version.

Checks on UE 2024.1 and 2024.3

What programming languages and tools are you using? Please provide specific versions.

Python 3.10

What Bazel plugin version are you using?

2024.11.19.0.3-api-version-243

Have you found anything relevant by searching the web?

NA

Any other information, logs, or outputs that you want to share?

NA

@andponlin-canva andponlin-canva added awaiting-maintainer Awaiting review from Bazel team on issues type: bug labels Dec 18, 2024
@github-actions github-actions bot added the product: IntelliJ IntelliJ plugin label Dec 18, 2024
@andponlin-canva andponlin-canva changed the title IJ selecting the incorrect Bazel target when debugging a test IJ selecting the incorrect Bazel target when debugging a Py test under transition Dec 18, 2024
@andponlin-canva
Copy link
Contributor Author

I have now been able to reproduce the problem. Find attached an example project;

See the README.md in the project for details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting-maintainer Awaiting review from Bazel team on issues product: IntelliJ IntelliJ plugin type: bug
Projects
Status: Untriaged
Development

No branches or pull requests

2 participants