it doesn't seem to see submodules

[amery]

I use submodules a lot, and by that I mean nested go.mod in the same git repository following what some people calls a MonoRepo.

unfortunately if I run golds -allow-network-connection -port 6060 -v . at a checkout of https://github.com/darvaza-proxy/slog for example, handlers/*/go.mod are ignored.

suggestions?

[amery]

and passing all the directories with a go.mod as argument leads to server.go:314: no packages matched (with or without trailing /...)

[zigo101]

@amery
It looks the submodules app require the root module.
This means there are more than one starting/seed modules.
Golds is unable to handle such situation: #25 (comment)

Thanks for submitting this issue, which let me find a bug in Golds.
This bug makes Golds fail to parse any single one of the submodules in the https://github.com/darvaza-proxy/slog project.
The bug will be fixed in the next release.

After the bug is fixed, Golds is able to parse any single one of the submodules, but still unable to parse them all at the same time.

[amery]

@go101 the pattern there is that the root defines an interface, and submodules implement it

[zigo101]

(moved from golang/go#59056):

Yes, as Golds provides some richer features, such as showing be-direction relations between deping and deped packages (such as type implementation relation), there are some difficulties to parse multiple versions of a package at the same time, which is often caused by parsing multiple seed modules.

I believe the limitation originates from the golang.org/x/tools/go/packages package, though it is possible to make (some heavy) efforts to let Golds work through the limitation.

wouldn't the dependency graph sort that instead of assuming the first package is the leaf?

@amery
I don't get what you mean. What is a leaf?

[amery]

@go101 a node on the graph who no one depends on

[zigo101]

The problem is two leaf/seed modules might require two different (minor) versions of a module.
Neither parsing both nor parsing either of the two versions is guaranteed to be without problems.

[amery]

The problem is two leaf/seed modules might require two different (minor) versions of a module. Neither parsing both nor parsing either of the two versions is guaranteed to be without problems.

I understand now what you meant, thanks