> If we just put 'go dep' as the hook to current draft dep, then users would need to run things like 'go dep ensure' and so on, and those would be the first ever go sub-sub-commands. That feels not quite right to me.
> We've avoided subcommands in the go command to date, and we should continue to avoid adding them unless it really makes the experience significantly better. In this case, it does.
So, I don’t see it as a contradiction to the mail you’re quoting :)
`go mod download` is for explicitly populating the cache. If you just run `go build`, the cache will be implicitly populated. You don't need to run `go mod download` before doing a build.
no it was added at the request of the athens project (github.com/gomods/athens) so there would be a canonical way to download modules that we could use to prime the cache.
12 comments
[ 12.5 ms ] story [ 836 ms ] thread> If we just put 'go dep' as the hook to current draft dep, then users would need to run things like 'go dep ensure' and so on, and those would be the first ever go sub-sub-commands. That feels not quite right to me.
From the commit message:
> We've avoided subcommands in the go command to date, and we should continue to avoid adding them unless it really makes the experience significantly better. In this case, it does.
So, I don’t see it as a contradiction to the mail you’re quoting :)
I opened the original issue in question due to lack of feature parity and it got quickly closed (https://github.com/golang/go/issues/26610#event-1753880630). Then after some twitter back-and-forth (https://twitter.com/sgnn7/status/1022547467466956802) the issue got reopened.
https://github.com/golang/go/commit/7aa9855704a766a1a16fbed7...
(main module does not need package generics)