https://pantsbuild.org/ logo
Join Slack
Powered by
Hi everyone, We're getting this error for the fir...
# general
a
Hi everyone, We're getting this error for the first time:
Copy code
FAILURE: Failed to fetch binary bin/thrift/mac/10.14/0.9.2/thrift from any source: (Failed to fetch binary from <https://binaries.pantsbuild.org/bin/thrift/mac/10.14/0.9.2/thrift>: Fetch of <https://binaries.pantsbuild.org/bin/thrift/mac/10.14/0.9.2/thrift> failed with status code 404)
Was the file removed because of the 1.14 update? We upgraded to 
1.14
a few weeks ago but pinned thrift to 
0.9.2
because we are still working through some kinks in the thrift upgrade itself.
a
so pants should be able to try an earlier version of osx to resolve binaries against, and i believe that feature is in 1.14, so that should be happening here -- what's the full command / output?
a
Hmmm it's thrown somewhere in a script, let me go find the person who reported this and hunt this one down.
a
ok, will jump into the code and refresh my memory on that bit
there is almost definitely a workaround
if the script sets 
binaries_path_by_id
globally in pants.ini or sets 
PANTS_BINARIES_PATH_BY_ID
in the env (possibly to work around a previous version of this issue), that could be causing it
the output of the command:
Copy code
> ./pants options | grep binaries_path_by_id
would be useful
a
Asked around, and the original problem is 
FAILURE: Unable to find binary thrift version 0.9.2. Update --binaries-path-by-id to find binaries for (u'darwin', u'18')
, which they tried to work around by adding:
Copy code
[binaries]
path_by_id: {('darwin', '18'): ('mac', '10.14')}
For context, I also have under the 
[DEFAULT]
section
Copy code
path_by_id: {('darwin', '18'): ('mac', '10.13')}
a
ah. so first, 
[binaries]
is a deprecated scope (which pants should be creating a warning about -- is it doing that?) -- the new option is global, just 
binaries_path_by_id
(it's confusing, and there's an options parsing bug in https://github.com/pantsbuild/pants/issues/5282 making it more confusing -- sorry about that!).
so i would remove all of those entries in your pants.ini and check to make sure the script or your shell isn't setting 
PANTS_BINARIES_PATH_BY_ID
a
so both the one in 
[binary]
and under 
[DEFAULT]
yeah?
a
yes!
if you've removed it and made sure the env var isn't set (or explicitly call 
unset PANTS_BINARIES_PATH_BY_ID
), and it continues to fail, then adding 
binaries_path_by_id: {('darwin', '18'): ('mac', '10.14')}
in 
[GLOBAL]
should solve the problem -- but i would ask you to make an issue if you can with any repro info you have at hand, since this is supposed to be fixed. it's possible we could do something more complex to detect if the option is being overridden, but it's not clear what the right behavior would necessarily be there
a
Hmmm I see, will see how that goes. For additional information, here's the output to the options:
Copy code
binaries_path_by_id = {(u’darwin’, u'18'): (u’mac’, u'10.14')} (from CONFIG in pants.ini)
a
ah, ok, thank you
also make sure the mac version corresponds to your osx version, but i assumed you are on osx 10.14?
a
Yeah we are on 10.14, just double checked
Just kidding. Turns out the problem was developer hasn't updated the repo in more than a year 'cause he usually works on a different project, and was still on 
1.4
derp. Really should have done all the fundamental checks first my bad.
👍 1
This is why all the tech support operators go through all those checks when you call them....
a
i'm very impressed and glad it was working for so long on 
1.4
though!
restarting always seems to help me personally
🔥 1
thanks for diving in and figuring it out! this sort of investigation is still useful to us
Open in Slack
PreviousNext
Powered by