> > It does in as much as adding missing dependencies are concerned, but
> > doesn't do the tidying (removal) in go.{mod,sum} that go mod tidy
> > does.
>
> I don't think this is true (unless this has been fixed, I can't upgrade to 
> check right this moment), go build respects build constraints (eg. you won't 
> get dependencies that only exist in tests), so even if you're just talking 
> about adding missing dependencies, build won't necessarily help you.

I should have been more precise. go build adds missing dependencies
that are required to complete go build. Similarly for other build/test
related commands, e.g. go list. Those commands are, by definition, a
function of GOOS, GOARCH and build tag constraints. So yes, the only
dependencies that would be added with such a command would be those
required to complete that command under any such constraints.

go mod tidy is not a build command and so not subject to build
constraints, hence ends up adding missing dependencies irrespective of
build constraints.

I don't think there's anything wrong with this distinction - when you
say "unless this has been fixed", are you suggesting the behaviour is
wrong or could be improved in some respect?

> I've noticed this causing a lot of confusion in libraries moving to modules 
> where dependencies get left out because they're hidden behind a build tag, or 
> only get added when tests are run.

go mod tidy is the correct way to fix go.{mod,sum} to ensure they are
complete and minimal. https://github.com/golang/go/issues/27005 will
also be useful when it lands to make CI-esque checks easier.


Paul

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to