Hi all, I’m running into the following error with ...
# general
b
Hi all, I’m running into the following error with `./pants run Dockerfile`:
Copy code
BuildKit is enabled but the buildx component is missing or broken.
Install the buildx component to build images with BuildKit:
<https://docs.docker.com/go/buildx/>
Notes: • I’m on an Intel-chip Macbook • I installed the most recent Docker Desktop • With
--keep-sandboxes=on_failure
, I can run the
__run.sh
and the docker build succeeds with
DOCKER_BUILDKIT=1
(and the image appears in my docker desktop) It seems like my Docker installation is able to build with BuildKit enabled, but when running through Pants it doesn’t detect buildx? I’m new to Pants, so any direction would very appreciated! Let me know what other information I can provide. Thanks!
1
c
Hi Chris, This sounds like an issue with one or more env vars missing due to Pants hermetic execution model. Have you added
DOCKER_BUILDKIT
to your
pants.toml
in order for it to propagate to the docker build command, or did you provide that when you ran
__run.sh
?
might be that you need to have
HOME
set as well.. or something like that.
b
Hi Andreas! Yes, it is set:
Copy code
[docker]
env_vars = ["DOCKER_BUILDKIT=1", ...]
When I try to run with
DOCKER_BUILDKIT=0
, I get this error:
Copy code
2023-05-08 11:14:26 Failed to find compatible interpreter on path /usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin.
2023-05-08 11:14:26 
2023-05-08 11:14:26 Examined the following interpreters:
2023-05-08 11:14:26 1.) /usr/local/bin/python3.9 CPython==3.9.16
2023-05-08 11:14:26 2.)       /usr/bin/python3.9 CPython==3.9.2
2023-05-08 11:14:26 
2023-05-08 11:14:26 No interpreter compatible with the requested constraints was found:
2023-05-08 11:14:26 
2023-05-08 11:14:26   A distribution for apache-beam could not be resolved for /usr/local/bin/python3.9.
2023-05-08 11:14:26   Found 1 distribution for apache-beam that do not apply:
2023-05-08 11:14:26   1.) The wheel tags for apache-beam 2.44.0 are cp39-cp39-macosx_10_9_x86_64 which do not match the supported tags of /usr/local/bin/python3.9:
2023-05-08 11:14:26   cp39-cp39-manylinux_2_31_x86_64
2023-05-08 11:14:26   ... 661 more ...
A couple questions regarding this: 1. Where are these paths coming from (e.g.
/usr/local/bin/python3.9
)--this does not exist on my system; is this referring to paths inside the docker image? 2. Why is it selecting
macosx_10_9_x86_64
? When I check my sysinfo from various python paths on my mac, I get
macosx-10.9-universal2
Are there more logs or more information I can provide you to help me understand which direction I should be looking?
c
that error message seems to come from running a pex inside a container, yes. One likely issue is that you built your pex on your Mac to run inside a container. That won’t work unless you take care to build the pex for the correct platform. See https://github.com/pantsbuild/pants/issues/14145 https://github.com/pantsbuild/pants/issues/13682 https://github.com/pantsbuild/pants/issues/13185
b
Ah okay thank you I will take a look at that!
@curved-television-6568 Hey! I’m still digging into this, but have a question for you in the meantime: Why is it that
./pants run Dockerfile
fails with
BuildKit is enabled but the buildx component is missing or broken
(no image is created), BUT when I go to the sandbox and run
__run.sh
(which runs
docker build
), the image builds successfully? Maybe relevant: Even though
__run.sh
successfully creates an image, subsequently running
docker run
on that image gives
Failed to find compatible interpreter on path
, which is the same error I get with
DOCKER_BUILDKIT=0 ./pants run Dockerfile
(mentioned above) Thanks for the help!
c
So, the
__run.sh
script you get in the sandbox is Pants best approximation of what it does when invoking that process. So if that works while Pants fails, there’s some little nuanced difference between the two, likely env var related.
Not sure about the interpreter issue. You’d want to make sure that the pex is trying to use the python you’d expect, and that there indeed exists such an interpreter in the image that it may use.
b
Alright, we upgraded to Pants 2.15 and we were able to fix the macOS to Linux cross-build issues with a
docker_environment
! 🎉 BUT…. I’m still running into this BuildKit/buildx issue 😕 Running
pants run Dockerfile
still gives the incessant
BuildKit is enabled but the buildx component is missing or broken.
error, despite definitely having buildx on my system, installed via Docker Desktop, and confirmed in
docker info
. Further, both of the following methods successfully build the docker image: 1. Run the
__run.sh
in the pants sandbox 2. Run my own bash script with all necessary
pants package
commands and
docker build
I cannot figure out why
pants run Dockerfile
is failing to detect buildx, while the other 2 approaches build the image without issue. Any guidance is greatly appreciated! Note:
pants run Dockerfile
does succeed if I set
DOCKER_BUILDKIT=0
in
[docker].env_vars
b
In pants 2.15,
__run.sh
isn’t yet fully hermetic (ie doesn’t fully simulate running within pants itself ) and may be leaking some env vars from your shell. Does running
env
in a shell reveal any potentially docker relevant env vars?
b
I don’t see any env variables that would cause issues in this context, other than perhaps my PATH being different from what Pants uses? I’m on a mac using Docker Desktop. Does Pants use the local Docker installation, or does it have its own packaged binary? Since my local commands have no issues finding the buildx path, wouldn’t this be an issue with how Pants is constructing its environment (and not my env vars leaking in)?
c
it uses the system docker, doesn’t have it’s own binary. Try in a sandbox to change the env setup to use the
-i
flag:
env -i …
that way, you get the same hermeticity as Pants.
in the
__run.sh
script
b
Forgot to follow up here: adding "HOME" to the env vars fixes the issue! (you alluded to this at the beginning of the thread haha but I got distracted by the other cross-platform issues I encountered) Thanks for the
env -i
tip! Using that, I found that it was indeed the HOME env var getting passed that allowed docker build to succeed when running
./__run.sh
👍 1
c
Thanks for the follow up. Fwiw, starting with Pants 2.17 the
env -i
flag will be provided in the
__run.sh
script already. https://github.com/pantsbuild/pants/pull/18582
b
ah awesome! so with that change,
__run.sh
will fully reproduce the hermiticity of pants?