https://pantsbuild.org/ logo
Join Slack
Powered by
Fun, I think that Pants has been running system Pe...
# development
h
Fun, I think that Pants has been running system Pex this whole time for me? John’s PR made me realize that. See https://travis-ci.com/github/pantsbuild/pants/jobs/366361029#L505. We’re trying to run 
pex
, rather than something like 
./pex
.
w
it wouldn’t be system, but it could be the one from pants’ venv…?
h
Ah, yeah, that makes sense. I’m putting up a fix for this as a precursor
w
but also, i think 
./
might not be necessary in this context… afaik, that’s a shell affordance
is it 
pex.pex
?
h
The binary is called 
pex
. By using 
./pex
, we are disambiguating that we want the local file 
pex
, and not to search the PATH
w
we’re not in a shell
so there is no path searching
but yea, i donno.
i do know that because there is no shell, the kernel directly executes the args
(and it or libc is what supports the shebang)
h
Hm, any idea what that error would be then? And is there anything wrong with prefixing 
./
? If anything, it makes the error messages less confusing imo
w
you’re 100% sure that that’s the name of the file inside the snapshot?
…and that it is included?
@hundreds-father-404: could inspect the run with 
--no-process-execution-cleanup-local-dirs
h
Yes, at least it is intended to be. The way 
ExternalTool
works is that you download either a single file or an archive, then set 
generate_exe()
to say what the path is to the binary within that archive There was an affordance that if the download is a single file, you can leave off the method, and we’ll guess the name of the exe. But we weren’t prefixing that with 
./
w
ok.
i just realized that what i said about PATH searching above is not true. you can directly invoke something that is in the PATH… we know, because we used to for 
python
here.
h
Exactly, that’s what I’m thinking
w
k. sorry for the smoke screen
h
That’s okay, this is really confusing stuff. I appreciate you talking it through!
Open in Slack
PreviousNext
Powered by