You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
In a Go codebase, the file result dependency graph shows each .go file as depending on all .go files inside each of its imported modules, instead of only the ones with exported members used in the given file.
Describe your environment
Ubuntu 23.04?
Python 3.11.4
Google Chrome Version 115.0.5790.170 (Official Build) (64-bit)
Private repo
Here is an example output with of the program with debug (-d) flag enabled:
...
2023-08-10 11:03:26 parser D ⏩ adding import: project/pkg/somepkg/gofile1.go
2023-08-10 11:03:26 parser D ⏩ adding import: project/pkg/somepkg/gofile2_test.go
2023-08-10 11:03:26 parser D ⏩ adding import: project/pkg/somepkg/gofile3.go
2023-08-10 11:03:26 parser D ⏩ adding import: project/pkg/somepkg/gofile1_test.go
2023-08-10 11:03:26 parser D ⏩ adding import: project/pkg/somepkg/gofile2.go
...
Only project/pkg/somepkg/gofile1.go contains exported members that are used in the file being processed, but all files under project/pkg/somepkg are added as dependencies.
To Reproduce
Steps to reproduce the behavior:
Create a config with at least dependency_graph and louvain_modularity scans enabled
Run the tool, go to the generated HTML
Open the file result dependency graph
See nonexistent dependencies between some nodes
Expected behavior
I'd expect only project/pkg/somepkg/gofile1.go to be added as a dependency and to see this reflected in the visualization.
Additional context
This issue is more evident in projects with many .go files under the same packages.
Given in Go you import by package, and not by file, it may be tricky to accurately represent dependencies between files. The Go standard library provides the go/parser and go/token packages, which can be used to parse Go files and analyze their abstract syntax trees (AST). That could be helpful, but I don't know how could it fit in this Python tool.
The text was updated successfully, but these errors were encountered:
Describe the bug
In a Go codebase, the file result dependency graph shows each
.go
file as depending on all.go
files inside each of its imported modules, instead of only the ones with exported members used in the given file.Describe your environment
Here is an example output with of the program with debug (
-d
) flag enabled:Only
project/pkg/somepkg/gofile1.go
contains exported members that are used in the file being processed, but all files underproject/pkg/somepkg
are added as dependencies.To Reproduce
Steps to reproduce the behavior:
dependency_graph
andlouvain_modularity
scans enabledExpected behavior
I'd expect only
project/pkg/somepkg/gofile1.go
to be added as a dependency and to see this reflected in the visualization.Additional context
This issue is more evident in projects with many
.go
files under the same packages.Given in Go you import by package, and not by file, it may be tricky to accurately represent dependencies between files. The Go standard library provides the
go/parser
andgo/token
packages, which can be used to parse Go files and analyze their abstract syntax trees (AST). That could be helpful, but I don't know how could it fit in this Python tool.The text was updated successfully, but these errors were encountered: