Closed piranha32 closed 6 years ago
Hi - I can take a look this weekend and update Fsq.io when I find the issue, which I expect won't be too hard.
I have the fix internally and will roll out in the next day or two (we land in our internal repo and then deploy to the foursquare/fsqio repo).
But the problem is from a hack I used to publish 1.2.0 buildgen modules to pypi. Landing that hack was always a risk but worth it since we have buildgen customers at 1.2.1. But those modules have been successfully published, so we can go ahead and restore the original state.
You can verify if this works for you by running:
rm -rf ~/.cache/fsqio
Applying the following patch:
diff --git a/3rdparty/python/requirements.txt b/3rdparty/python/requirements.txt
index 69ea9c91..a2456b6d 100644
--- a/3rdparty/python/requirements.txt
+++ b/3rdparty/python/requirements.txt
@@ -5,10 +5,10 @@ opentracing==1.2.2
# The pantsbuild libs can stay as a loose constraint - the version invoked at build time is set in
# the pants.ini, so this range is only used for the Fsq.io contrib modules published to PyPi.
-pantsbuild.pants.contrib.go>=1.2.0
-pantsbuild.pants.contrib.node>=1.2.0
-pantsbuild.pants>=1.2.0
-pantsbuild.pants.testinfra>=1.2.0
+pantsbuild.pants.contrib.go==1.3.1rc1
+pantsbuild.pants.contrib.node==1.3.1rc1
+pantsbuild.pants==1.3.1rc1
+pantsbuild.pants.testinfra==1.3.1rc1
psycopg2==2.7
pymongo==2.8
py_zipkin==0.9.0
And running
./pants compile test src:: test::
Unless you tell me this doesn't solve your issue, I will close this when I update the Fsq.io repo with those fixes
This fix has been merged at HEAD, tagged as fsqio-2018-03-20-0242
Sorry for late response, I've just got to test it. The patch fixed the problem on linux, haven't had a chance to test on Mac yet. Thanks for fixing it.
Build of freshly cloned fsqio crashes with the following messages:
OSX and Fedora 27 are affected by the issue, I don't have access to other systems to test.