https://pantsbuild.org/ logo
#general
Title
# general
g

gorgeous-winter-99296

10/31/2022, 9:40 PM
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.
h

hundreds-father-404

10/31/2022, 9:42 PM
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?
g

gorgeous-winter-99296

10/31/2022, 9:45 PM
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.
👍 1
h

hundreds-father-404

10/31/2022, 9:46 PM
what if we allowed
go_binary
to point to a
go_third_party_package
via the
main
field?
g

gorgeous-winter-99296

10/31/2022, 9:47 PM
Yes; or;
go_third_party_binary
?
h

hundreds-father-404

10/31/2022, 9:47 PM
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
g

gorgeous-winter-99296

10/31/2022, 9:48 PM
Then your approach + auto-generating the go_binary too? 😛
h

hundreds-father-404

10/31/2022, 9:50 PM
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
g

gorgeous-winter-99296

10/31/2022, 9:51 PM
But package main cannot be imported elsewhere, so the only thing I can do with it is to wrap it in a
go_binary
h

hundreds-father-404

10/31/2022, 9:53 PM
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:
Copy code
go_binary(
  name="controller-tools",
  main="src/go#<http://github.com/controller-tools/cmd/controller-gen|github.com/controller-tools/cmd/controller-gen>",
)
g

gorgeous-winter-99296

10/31/2022, 9:55 PM
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.
I.e., I can either not use it or I do the boilerplate of writing a
go_binary
. So why not skip/automate the boilerplate?
h

hundreds-father-404

10/31/2022, 9:58 PM
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
What's the motivation with avoiding having the
go_binary
pointing to a
go_third_party_package
? Boilerplate, or something else too?
g

gorgeous-winter-99296

10/31/2022, 10:00 PM
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
. 🙂
h

hundreds-father-404

10/31/2022, 10:03 PM
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
g

gorgeous-winter-99296

10/31/2022, 10:06 PM
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.
h

hundreds-father-404

10/31/2022, 10:08 PM
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"
Would you be interested in implementing this? I'm happy to point you at the relevant parts of the code
g

gorgeous-winter-99296

10/31/2022, 10:10 PM
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. 😛
❤️ 1
h

hundreds-father-404

10/31/2022, 10:11 PM
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
g

gorgeous-winter-99296

10/31/2022, 10:12 PM
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.
👍 1
4 Views