Re 1: Sources are preferable for us, in accordance with the report I submitted at https://github.com/golang/go/issues/24088
. We do quite often need to browse sources of third-party libs, be it:
- for understanding what really happens (if godoc is unclear),
- or fixing bugs (in our code or the library code; esp. w.r.t. races).
- Also for evaluating viability of a fork to tweak the lib to our needs.
By the way, this now reminded me that we have similar needs w.r.t. the Go stdlib from time to time. Now that I think of it, would feel very weird if browsing the standard library source was easier than browsing third party libs sources.
Re 2: Feels irrelevant to me; cannot think of any reason why one or the other would make any difference.
Re 3: Mostly what other people mentioned:
- both for CI builds (on specialized server) and dev builds (on workstations), it should be trivial to reproduce our whole app ecosystem from our monorepo, with an assurance that nothing is downloaded from the Internet;
- it should be trivial for devs to add new libraries with transitive dependencies to the monorepo;
- it should be trivial for devs to prune the monorepo of unused dependencies (transitively).
I'm mentioning the monorepo instead of "module" or "go.mod", as this is what's of concern to us personally. I see notion of "module" or "go.mod file" as a mostly irrelevant artifact.
Some extra notes Re 3:
- notably, it would be preferable for us if vgo could fetch all dependencies for *all combinations of GOOS+GOARCH* we support, and merge them all into our monorepo. If basic 'vgo get' is additive, then this might be only relevant to a theorized 'vgo prune'. In case of our in-house vendoring tool, we chose to follow an algorithm of: 1) prune whole vendor.json; 2) iterate all GOOS+GOARCH combinations and additively fetch required packages from disk (if available) or network (otherwise). Notably, there's no need to further iterate GOOS+GOARCH when recursing through transitive dependencies.
- I completely forgot that we actually tried to open-source the tool at some point in time (though we didn't have enough resources to find time to write at least a readme, unfortunately). The code dump is at: https://github.com/zpas-lab/vendo/
. Notably, a study of use-cases which preceded it is at: https://github.com/zpas-lab/vendo/blob/master/use-cases.md
, complete with high level drafts of the algorithms used.