Repository navigation
ENH: Add a bool argument index_dependencies to the add_code_to_graph tool #53
Description
When this bool is set to true, start indexing all the Python packages in the import tool. All imports are already traced while parsing each file.
When set to False, perform the same operations as being done now
Metadata
Metadata
Assignees
Type
Projects
- Status
- Status
Activity
yashraj4 commentedon Oct 3, 2025
Hi @Shashankss1205 👋,
I’d like to work on this issue. I will also add/update tests to validate both modes.
Could you please assign this issue to me so I can start working on it?
Shashankss1205 commentedon Oct 3, 2025
I want to know both of yours course of action before assigning. This is asked because I was having trouble back when I was starting to implement this. @yashraj4 @Dwid4r
yashraj4 commentedon Oct 5, 2025
I will modify the
add_code_to_graphtool in two main places withinsrc/codegraphcontext/server.py:Tool Schema: Update the
_init_toolsmethod to let the AI know about the newindex_dependenciesargument.Tool Implementation: Update the
add_code_to_graph_toolmethod to add the new logic for finding and indexing dependencies.eshaanag commentedon Jun 3, 2026
I would like to work on this as part of GSSoC 2026 if it is still open for assignment.
I read through the issue and the earlier maintainer comment asking for a concrete course of action before assigning. I also checked the current code paths:
src/codegraphcontext/tool_definitions.pyalready exposesadd_code_to_graph, but only withpathandis_dependency.src/codegraphcontext/tools/handlers/indexing_handlers.pyhas theadd_code_to_graphhandler and a separateadd_package_to_graphflow.src/codegraphcontext/tools/package_resolver.pyalready has language-specific package lookup helpers, including Python viaimportlib.util.find_spec.My approach would be to keep this scoped to Python first, since the issue specifically mentions Python packages and the resolver support is already present:
index_dependencies: falseflag to theadd_code_to_graphtool schema, without changing the current default behavior.is_dependency=True, while skipping packages already indexed.index_dependencies=Trueshould attempt to resolve/index external imports only.The main thing I want to be careful about is avoiding runaway indexing from large virtualenv/site-packages trees, so I would add limits/duplicate checks rather than blindly walking every imported package.
Please assign this to me if this direction looks reasonable.
Shashankss1205 commentedon Aug 2, 2026
Cross-reference from #62 (closed into this one): the reported symptom is that a resolved call produces no edge because the callee's package was never added to the graph —
use_random→randintresolves in the logs but noCALLSedge is created.Two things worth deciding as part of the design here:
stdlib vs third-party may need different handling. ENH: Packages and their methods are not present as nodes #62's example is
random, butpackage_resolver._is_stdlib_moduleexists specifically to classify and exclude stdlib. "Index all imported packages" probably shouldn't pull in all of CPython's standard library by default — worth an explicit sub-flag or policy.bug(indexer):
add_package_to_graphon a flat module (six,typing_extensions) resolves to the entire site-packages directory and indexes the whole environment #1528 should be fixed first.add_package_to_graphon a flat single-module package (six,typing_extensions) currently resolves to the wholesite-packagesdirectory. Turning on automatic dependency indexing on top of that bug would index the entire virtualenv.Shashankss1205 commentedon Oct 15, 2026
Maintenance review — 15 October 2026
Dependency indexing appears in draft #1733 alongside role prompts. Keep it opt-in and scoped separately: test enabled/disabled behavior, dependency cycles, sandbox boundaries and unavailable packages before closing this issue.