Open cbgbt opened 5 months ago
When twoliter searches for golang modules, it recursively finds all go.mod files and assumes that a module exists with the parent directory name.
go.mod
Consider golang sources arranged as such under the sources directory:
sources
hello-go ├── cmd │ └── hello-go │ └── main.go ├── embedded-mod │ ├── cmd │ │ └── embedded │ │ └── main.go │ └── go.mod └── go.mod
In this case, find_go_modules() will return ["hello-go", "embedded-mod"]. When fetching vendored dependencies, twoliter later assumes that all configured GO_MODULES will live directly under sources.
find_go_modules()
["hello-go", "embedded-mod"]
GO_MODULES
The solution to this may be as simple as having find_go_modules() return the module path relative to sources, but I haven't looked more deeply into what impact this has on how golang tooling is later invoked.
When twoliter searches for golang modules, it recursively finds all
go.modfiles and assumes that a module exists with the parent directory name.Consider golang sources arranged as such under the
sourcesdirectory:In this case,
find_go_modules()will return["hello-go", "embedded-mod"]. When fetching vendored dependencies, twoliter later assumes that all configuredGO_MODULESwill live directly undersources.The solution to this may be as simple as having
find_go_modules()return the module path relative tosources, but I haven't looked more deeply into what impact this has on how golang tooling is later invoked.