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

[python] query across modules that are not part of the same package doesn't seem to work #464

Open
giovanni-guidini opened this issue Sep 30, 2024 · 0 comments

Comments

@giovanni-guidini
Copy link

Hi, I've recently been trying to use the tree-sitter-stack-graphs-python (the CLI ) to query definition of references in a project.

What I'm noticing is that for references that are not defined in the same "package", the query doesn't return the actual definition. Even if all files from reference to definition are indexed, the query stops at the import statement on the file with the reference. Please see context for the example. Questions below

Context

What works

Using the example in the blog post that uses stove.py, kitchen.py and chef.py to query for the broil reference I get the actual function definition in stove.py, as expected.
image

tree-sitter-stack-graphs-python query --database=indexes/test_project definition ./test_project/chef.py:3:1
.../test_project/chef.py:3:1: found 2 definitions for 2 references
found 2 references at position
   0: queried reference
      .../test_project/chef.py:3:1:
      3 | boil()
        | ^^^^

      has no definitions
   1: queried reference
      .../test_project/chef.py:3:1:
      3 | boil()
        | ^^^^

      has 2 definitions
      .../test_project/chef.py:1:21:
      1 | from kitchen import boil
        |                     ^^^^
      .../test_project/stove.py:5:5:
      5 | def boil():
        |     ^^^^

What doesn't work

By modifying the project structure to have the stove.py and chef.py in different packages (still submodules of the project) the query then stops at the import statement in chef.py (so it finds only 1 definition, not the second one I'm more interested in).

I'd expect that querying the boil reference from staff/chef.py:3:1 would show the definition of boil in kitchen/stove.py, given that the path to the definition is all indexed on the graph database.

Modified project structure
.
├── test_project/
│   ├── kitchen/
│   │   ├── __init__.py
│   │   └── stove.py
│   └── staff/
│       ├── __init__.py
│       └── chef.py
└── __init__.py
Query results
tree-sitter-stack-graphs-python query --database indexes/test_project d
efinition ./test_project/staff/chef.py:3:1
.../test_project/staff/chef.py:3:1: found 1 definitions for 2 references
found 2 references at position
   0: queried reference
      .../test_project/staff/chef.py:3:1:
      3 | boil()
        | ^^^^

      has no definitions
   1: queried reference
      .../test_project/staff/chef.py:3:1:
      3 | boil()
        | ^^^^

      has definition
      .../test_project/staff/chef.py:1:21:
      1 | from kitchen import boil
        |                     ^^^^
File contents
# path test_project/kitchen/__init__.py
from kitchen.stove import *

# path test_project/kitchen/stove.py
def boil():
    print("boiling...")


def saute():
    print("sauteing...")


def simmer():
    print("simmering...")

# path test_project/staff/chef.py
from kitchen import boil

boil()
Files indexed
tree-sitter-stack-graphs-python status --database indexes/test_project --all
.../test_project/__init__.py: indexed
.../test_project/kitchen/__init__.py: indexed
.../test_project/kitchen/oven.py: indexed
.../test_project/kitchen/stove.py: indexed
.../test_project/staff/__init__.py: indexed
.../test_project/staff/chef.py: indexed

Questions

Why doesn't the query return kitchen/stove.py as a definition for boil?

Do I have to make multiple queries to get to the definition myself? That is, is what I'm seeing the expected behavior?

Also, am I forgetting something?
(I've just started to use this tool, so it is very likely that I am simply skipping some step)
(or that my expectation is not the expected behavior)

Thanks :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant