#17427 External go `main` packages should be runnable New issue created by tgolsson Is your feature request related to a problem? Please describe. I'm trying to use https://github.com/kubernetes-sigs/controller-tools as a code-generator without building a whole sub-system around it1. I noticed that this isn't currently possible to do, as I can't run a binary in an external repository. Describe the solution you'd like I'd like the external package to be runnable. If

<http://github.com/org/repo|github.com/org/repo>

has a

cmd/hello

which is a main package I would want

pants run //:root#<http://github.com/org/repo/cmd/hello|github.com/org/repo/cmd/hello>

to run it, at a minimum. This is unambiguous because that cannot be imported, so there's no need for it to be a package. This'd entail replacing or supplementing the current

go_third_party_package

with a

go_binary

target. I'd give the binary target priority here since the

go_third_party_package

doesn't provide any useful actions. While a bit out of scope for the immediate feature ask (which I've offered to tackle), I think there's also other concerns here. Making

package main

a valid "package" in the build graph seems like it potentially can lead to unexpected behaviors. Right now you can depend on the external main package in your build files without it being used. I've tried to enumerate a few different combos here: https://github.com/tgolsson/example-pants-first-party/blob/main/pkg/BUILD. The first ones work as expected, and the last bunch work despite being "ill-formed" in various ways. I think from a discoverability perspective it'd make more sense (to me!) to delineate the based on what kind of package it is to go. So runnable packages are disjoint from importable packages, not just wrappers. Go already knows this difference... and tailor does for the local workspace. As mentioned, properly out of scope... but I had 2 cents and I'd hate to waste them. 😂 Describe alternatives you've considered Not really solvable at all currently. The minimal work is just making

go_binary

accept a

go_third_party_package

as well as a

go_package

. Better/more explicit design is a lot more work (see discussion above). Additional context Slack question here: https://pantsbuild.slack.com/archives/C046T6T9U/p1667252451022069 Footnotes 1. I don't know if I can build a subsystem around a go package; but I assume it'd require a lot of plumbing at a minimum. :leftwards_arrow_with_hook: pantsbuild/pants