We've discussed this multiple times before with the tooling/modules folks, mostly on Slack and on the golang-tools monthly calls. The only written down notes I could find right now are #27887 (comment); @bcmills @rogpeppe @jayconrod @myitcv might have more links.

The provided solution uses go lists template ability to filter out indirect dependencies.

go list -f '{{if not .Indirect}}{{.}}{{end}}' -u -m all

I don't think it's reasonable to expect users to type this out every time. A bash alias can be created, but that's not portable and has the same problems as using an external tool (you have to know about it, and set it up).

The common use-case for people developing module tooling is not the same as for people consuming the module tooling. I think that most people just want to know if they have any dependencies to go get -u. Usually in Go, simple thing are simple to do, but complex things are still possible. go list only gives us that second half.

edit: I suppose what I actually want is a veneer on top of go list (ex: go mod updates).

I think this would be good to have. It's pretty common to want to list or upgrade direct dependencies of packages in the main module. It's too hard to do that with go list right now. Some thoughts though:

• go get -d direct should work, too, not just go list -m -u direct.
• We need a clear definition of direct. When lazy loading is implemented (cmd/go: module graph pruning and lazy module loading #36460), the set of modules required in go.mod will expand, so I don't think it would make sense to define direct module dependencies as those required in go.mod. Even today, there may be // indirect requirements, and those dependencies may not be listed anywhere else. Maybe it should be defined at the package level as "the set of packages directly imported by packages in the main module".

An alternative to direct is imported.

go list -m -u imported

Some overlap here with #28424.

Thanks @thepudds. Sorry we missed discussing that one. What do you think about this proposal vs the other?

/cc @jayconrod @bcmills; what's the status of this?

cc @matloob

I think the idea is good, but I'm not sure about the CLI specifics.

• The direct keyword seems a little terse. I'm not sure go list direct will make sense to someone unfamiliar with it. Any other keyword suggestions?
• I'd prefer direct over imports, since we'd want direct to cover both package and module dependencies, depending on whether -m is used.
• Would go list -m direct just list requirements in go.mod? That won't be all that useful after lazy loading (cmd/go: module graph pruning and lazy module loading #36460) because go.mod will list all modules needed to build packages in the main module, not just those providing directly imported packages.
• direct seems like more of a function than a set. In this proposal, we're talking about direct dependencies of the main module, but we might want to be able to get the direct dependencies of another set of packages: go list direct(example.com/m/...). Personally, I'd love to have a query language like bazel query, with functions like rdeps and somepath. But that's certainly overcomplicating things. If we eventually did that, direct on its own could still imply the main module or its packages.

The direct keyword seems a little terse.

Heh, I had a bit of the opposite reaction! All of the existing meta-packages (all, std, cmd) are three letters, so I was kind of hoping we could find another suitable three-letter pattern. (But I can't think of one at the moment.)

Would go list -m direct just list requirements in go.mod?

I think it should list only those requires that are not labeled with an // indirect comment.
That admittedly assigns semantic meaning (as an input) to comments that were previously only an output (produced, but not semantically consumed by, the go command), but I think it's more in line with user intent for the direct keyword.

Or, we could disallow the direct pattern with the -m flag, although that would arguably make the direct pattern less useful.

direct seems like more of a function than a set.

I agree that it would be nice for go list to support querying “the packages directly imported by the named packages”, but I think that feature should be mostly orthogonal to the one proposed here.

(I think the hypothesized go list query is more closely related to the -deps flag than to the all pattern.)

Or, we could disallow the direct pattern with the -m flag, although that would arguably make the direct pattern less useful.

Using it with -m is my primary use-case.

It sounds like people are saying:

• In go list direct, direct expands to a list of all the packages directly imported by the current module.
• In go list -m direct, direct expands to a list of all the modules providing those packages.

That is, direct becomes a pseudo-name like std and cmd and all that expands to this meaning in all commands, not just go list. But like with go list -m all, the meaning of direct changes for go list -m (as it must, since -m is about modules, not packages).

Do I have that right? Does anyone object to that?

Re #28424

It seems that the direct pseudo-name should also work with go get.

go get -u direct

Based on the discussion, this seems like a likely accept.

(If accepted, this would not be until Go 1.17. There's already a lot for Go 1.16.)

In go list -m direct, direct expands to a list of all the modules providing those packages.

Just so I understand, this would be a subset of the modules listed in go.mod without // indirect after a go mod tidy, right? Since lazy module loading can also add lines to go.mod for indirect modules without // indirect as far as I remember.

No change in consensus, so accepted.

You would see updates here if there were any; please don't ask like that, as it just adds pressure.