proposal: cmd/go: mark test dependencies in go.mod and go list -m

[DeedleFake]

There have been a number of requests for a test dependencies section in go.mod. These requests actually don't make sense with the way that go.mod works, because it's really just a list of rules to follow for resolving dependencies, not a list of dependencies. The actual list of dependencies is per-package, not per-module, and is determined by the actual import statements in the code itself. The go tool, however, does add some extra information to the go.mod file in the form of an // indirect comment after dependencies that are only depended on by a dependency.

I propose adding an alternate comment flag, test, to indicate that a dependency is only required by tests. Along with this, add an indication of this to the Module struct used for formatting go list -m output.

[komuw]

I tried implementing this sometime back as a cli at; https://github.com/komuw/ote (has bugs).

I would be in favor of the go tool adding // test comment.

[cndoit18]

any update?

[dfawley]

I'm curious about the state of things here, given this is 3.5 years old now.

Do Go users care about auditing transitive dependencies via go.mod entries? As a maintainer of gRPC, we have had related issues reported to us in the past, but I'm not sure if the status quo has changed since then.

Should we attempt to minimize the list of dependencies in go.mod even for testing-only or optional packages, by utilizing submodules? Or should we just use whatever we want in our tests and not worry about the implications in go.mod?

This feature request would help prevent those worries, but maybe it's unnecessary if the ecosystem no longer is concerned about go.mod contents and instead knows to focus on go list.

[ianlancetaylor]

CC @matloob @samthanawalla

[matloob]

I'm split on this. I think it would definitely be helpful to see which dependencies are test dependencies (especially when doing code review of a go.mod file). But I wonder if it would be better to surface this information in other tools?

I definitely don't think we should use submodules to minimize testing only dependencies. Module pruning treats tests different than other dependencies, so a test dependency in a go.mod isn't going to affect other modules that depend on your module the way a non-test dependency would.

[komuw]

But I wonder if it would be better to surface this information in other tools?

I created https://github.com/komuw/ote for this. Here's an example mod file rendered using that tool; https://github.com/komuw/ong/blob/main/go.mod
YMMV