Can I somehow run an external go dependency? E.g. with python I can make a working

pex_binary

from a dep+name of entrypoint in the dep, but it doesn't seem like I can run a

go_third_party_package

. Context: Want to https://github.com/kubernetes-sigs/controller-tools to generate code.

Hi! Right now, the best I could think of is create a

go_binary

target. But that requires that you have a

go_package

target with the package name set to

main

, so you would essentially have first-party code that invokes the third-party code. Would that work?

No; I don't think that'd make sense - since it's already a

main

package it doesn't really export anything meaningful I can use.

what if we allowed

go_binary

to point to a

go_third_party_package

via the

main

field?

Yes; or;

go_third_party_binary

?

we generally try to avoid a proliferation of targets when feasible. Here, I think every field would be applicable to both first and third-party: https://www.pantsbuild.org/docs/reference-go_binary

Then your approach + auto-generating the go_binary too? 😛

To be clear,

go_binary

is only a target you define in your BUILD file. It doesn't require you to have any specific code present. It only needs the

main

field to point to a valid

go_package

, which we default to the same directory of the BUILD file I'm suggesting that we loosen the

main

field to either point to a

go_package

or

go_third_party_package

. So, you woulndn't need to auto-generate anything 🙂 Only add the 1-3 line target to your BUILD file

But package main cannot be imported elsewhere, so the only thing I can do with it is to wrap it in a

go_binary

I don't think I understand. My understanding is you would have a

go_third_party_package

like

<http://github.com/controller-tools/cmd/controller-gen|github.com/controller-tools/cmd/controller-gen>

, and then you set this:

go_binary(
  name="controller-tools",
  main="src/go#<http://github.com/controller-tools/cmd/controller-gen|github.com/controller-tools/cmd/controller-gen>",
)

Yeah. But the only thing I'm allowed to do with

src/go#<http://github.com/controller-tools/cmd/controller-gen|github.com/controller-tools/cmd/controller-gen>

is to make it a

go_binary

.

package main

cannot be a dependency elsewhere.

Generally, you're not expected to ever manually define

go_third_party_package

and it's expected to always be generated by

go_mod

. So, automating this would look like allowing you to directly run/package any

go_third_party_package

, rather that manually defining some target. We could do that, but then we miss important fields like

restartable

and

output_path

, and people may try running packages that don't make sense

It is generated. Since it knows where a package exists, it should be able to note that it's a

package main

and also output a

go_binary

. I don't think all packages should be runnable; only those that are named

main

. 🙂

Oh, like the

go_mod

generate a

go_binary

target for you? Yeah we could theoretically do that, but it results in some weirdness like a) what is the address for it, given that the package name is already claimed b) if you want to set

restartable

etc, then you now need to use

overrides

, which is a little awkward/less discoverable Either way though, the first step we'd need to do is improving

go_binary

to work with

go_third_party_package

. That's still a possible future improvement to auto-generate that

go_binary

target from

go_mod

1. Good point - coming from bazel it's not ambiguous in the same way. (Though -

go_third_party_binary

solves that since it cannot be passed elsewhere that expects a package - the current way of writing it opens up for writing incorrect dependencies.) 2. Sure. Or manually write a go_binary rule from scratch.

Or manually write a go_binary rule from scratch.

Yeah. Although at that point, I'd bias towards "keep it simple" and "keep it explicit", and have users write the 1-2 lines in a BUILD file. We try (but often fail) to avoid complex edge cases of "do this most the time! but if that fails, do this whole other thing"

I can take a peek for sure! I think I know where to look; otherwise I'll get back to you. I've looked at how the Go backend works while implementing my OCI builder. 😛

Awesome! Either way, would you be willing to open a ticket please summarizing some of this convo? That will help to make sure this idea doesn't get lost even if you don't have the time to implement now

Will do tomorrow; quite late where I am now. I'd like to see if I can force a "bad linkage" by using the main package as a dep.