tool is a meta package, and go get accepts one or more packages.

closing as working as intended

Related Issues

• cmd/go doesn't recognize forward go directive when tool section is present in go.mod #70949 (closed)
• cmd/go: Inconsistent with input #48044 (closed)
• affected/package: golang.org/x/tools #55912 (closed)
• go build #52634 (closed)
• import/path: issue title #69545 (closed)
• cmd/go: build failed #59694 (closed)
• Test #67906 (closed)
• Bugs-Report #62338 (closed)
• go #49423 (closed)
• run #70024 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

meta modules should not be go got.

I suggest to reopen this issue.

@aclements @ianlancetaylor

you can go get all to update all you dependencies, tool is no different

Imho if I can‘t get/update a meta package, trying to do so should result in an error.

At least tool should not be allowed to be mixed with other ones.

BTW, tools is a better name in my opinion.

go get tool will update the set of tools you have installed (maybe 0).

tool was an explicit decision. #48429 (comment)

The name is unfortunate in my opinion.

And again, tool should not be allowed to be mixed with other module names.

Kindly ping @aclements @ianlancetaylor

Do you think it's a good idea to allow meta module names to be mixed with regular module paths?

you may want it to set dependencies at specific versions.

go get tool dont.upgrade/this@v0.1.0

Wouldnt that be the exact mistake I have made?

-tool

it should be?

@seankhliao

go get tool dont.upgrade/this@v0.1.0

Is dont.upgrade/this@v0.1.0 expected to be a tool module or a non-tool module here?

@aclements @ianlancetaylor @seankhliao

It looks to me that using go get tool to update all tool dependencies is a bad idea.
It should be go get -tool all instead. How do you think?

@seankhliao

Did you hide my comment in #48429 (comment)?

It looks that after running

go get -tool github.com/gokrazy/tools/cmd/gok@main

the following two commands are equivalent:

go get -tool github.com/gokrazy/tools/cmd/gok
go get github.com/gokrazy/tools/cmd/gok

In other words, tool dependencies and main dependencies are not distinguishable.
And tools and main code can't depend on different versions of a dependency module.

It looks the tool meta module name is not much meaningful. All its uses should be used -tool without other module paths instead.

I can definitely see the potential for confusion between go get -tool x and go get tool x. It follows from usage of go get that has been in place for a long time, but it's still unfortunate. However, it does not follow that "the tool meta module name is not much meaningful." It's just as meaningful as all.

It would not be viable to add a blanket rule that you can't mix meta-module names and regular module paths, since that's sure to break at least some existing usage. So the best we could do is a special case that disallows mixing specifically tool with regular module paths (as suggested by @zigo101).

I'm inclined to leave this as is and not add any more complexity or special cases for this. The consequences of mistaking go get -tool x and go get tool x are surprising and perhaps annoying, but do not seem particularly bad. Since a tool is almost certainly a "main" module, go get tool x doesn't actually add x to your go.mod at all. You're probably going to run go tool x shortly thereafter and it'll tell you "no such tool x", at which point you'll realize something went wrong. It's not exactly an ideal user journey.

Maybe trying to go get a main package should print a useful message. I was surprised I couldn't find any existing issues about this. If we were to do that, I think it would be reasonable to notice the user also said tool and hint that maybe they meant -tool.