https://pantsbuild.org/ logo
Join Slack
Powered by
The wheel building jobs are failing due to a failu...
# development
f
The wheel building jobs are failing due to a failure to find `go`:
Copy code
pants.core.util_rules.system_binaries.BinaryNotFoundError: Cannot find any `go` binaries using the option `[golang].go_search_paths`: ['/github/home/.cache/pants/pants_dev_deps/Linux.aarch64.aarch64.py39.venv/bin', '/opt/python/cp39-cp39/bin', '/opt/python/cp38-cp38/bin', '/opt/python/cp37-cp37m/bin', '/github/home/.cargo/bin', '/opt/rh/devtoolset-10/root/usr/bin', '/usr/local/sbin', '/usr/local/bin', '/usr/sbin', '/usr/bin', '/sbin', '/bin']
https://github.com/pantsbuild/pants/actions/runs/3905384605/jobs/6672312872
This is happening on 
main
after I landed https://github.com/pantsbuild/pants/pull/17973
cc @happy-kitchen-89482
I will add 
go
to those jobs for now but blindly creating a synthetic target even if there are no go targets may be something to avoid. Thoughts?
h
What changed?
f
if the Go backend is enabled, we add a synthetic target for the Go SDK
it is a target generator and calls 
go
to figure out what SDK-related targets to generate
and target generation is eager
h
But wasn't this all true before?
f
no it wasn't. previously we had no targets to represent the SDK itself
the PR linked above added this behavior
but this brings up the topic of making target generator be lazy to avoid Pants requiring ultimately unused tooling to be in place.
weird. the ARM build wheels job failed to install Go but the other wheel jobs did: https://github.com/pantsbuild/pants/actions/runs/3906037485/jobs/6673758791
Copy code
Run actions/setup-go@v3
/snap/bin/docker exec  fec02905a1d1797c612bcea3f879ef60c4461162719fc19ce7ef395d44ab3dc7 sh -c "cat /etc/*release | grep ^ID"
Setup go version spec 
/bin/sh: version: command not found
Error: Command failed:  version
/bin/sh: version: command not found
h
The linux arm wheels jobs are brand new, so...
actually not that surprising, that job is different because we don't run as root in the container
We can install Go in the image though
I can look at it
f
thanks!
h
It occurs to me that we could also disable the go backend during wheel building?
f
yes that should work also
h
Might be easiest.
👍 1
f
you might also need to have pants also ignore 
testprojects/src/go
(if it isn't already ignored)
otherwise those 
go_*
targets won't be recognized
h
Ah crap, we need go anyway because during the wheel build we install the wheels with enabled backends in order to smoke test that they install
so back to installing it in the image
f
something for tomorrow: I can probably have the Go synthetic target rule avoid generating the 
_go_sdk
target if there are no other Go targets in the repository
h
Open in Slack
PreviousNext
Powered by