[syvolt]

I have tested it and probably will use it but the fact that it pollutes your go.mod's indirect dependency list (without any distinction indicating it's for a tool) is very annoying.

[cirwin]

Primary contributor to the feature here.

We went back on forth on this a lot, but it boiled down to wanting only one dependency graph per module instead of two. This simplifies things like security scanners, and other workflows that analyze your dependencies.

A `// tool` comment would be a nice addition, it's probably not impossible to add, but the code is quite fiddly.

Luckily for library authors, although it does impact version selection for projects who use your module; those projects do not get `// indirect` lines in their go.mod because those packages are not required when building their module.

[syvolt]

Thank you for working on it. It is a nice feature and still better than alternatives.

I'm not a library author and I try to be careful about what dependencies I introduce to my projects (including indirect dependencies). On one project, switching to `go tool` makes my go.mod go from 93 lines to 247 (excluding the tools themselves) - this makes it infeasible to manually review.

If I'm only using a single feature of a multi-purpose tool for example, does it matter to me that some unrelated dependency of theirs has a security issue?

[eadmund]

> it boiled down to wanting only one dependency graph per module instead of two

Did you consider having tool be an alias for indirect? That would have kept a single dependency graph per module, while still enabling one reading one’s go.mod by hand rather than using ‘go mod’ to know where each dependency came from and why?

I know, a random drive-by forum post is not the same as a technical design …

[caust1c]

Having not looked at it deeply yet, why require building every time it's invoked? Is the idea to get it working then add build caching later? Seems like a pretty big drawback (bigger than the go.mod pollution, for me). Github runners are sllooooow so build times matter to me.

[arccy]

There's module graph pruning https://go.dev/ref/mod#graph-pruning

[movedx]

What solution would you propose?

[rplnt]

At least a comment if not its own section.

[jamietanna]

Yeah, I'm still rather excited about it, but less-so given it /does/ impact the `go.mod` for consumers