Open linzhp opened 4 years ago
Hey,
I am not against not using go list
but using it fixed a couple bugs for use. The advantages we gained by it were:
example.com/foo
but the package in foo
is actually bar
.example.com/foo/v2
where the package in v2 is bar
(or this could be foo
as well).If we can find a solution that covers these cases, tests should exist for these, and does not use go list
I am all for it. It is not great having to exec something from a binary, but it was a simple solution built into the tooling that fixed some bugs.
I have not looked into this yet, but there could also be extra flags we pass into go list
to filter down the amount of packages it scans.
@plakhotnii @codyoss
go list
is quite slow because it has to download external dependencies. This becomes more problematic under Bazel execution environment when GOCACHE is not available (https://github.com/bazelbuild/rules_go/issues/2366). I found all mockgen need fromgo list
is the package path. Why not deduce the package path from source file or directory in mockgen, using logic like:Related to #396