https://pantsbuild.org/ logo
Join Slack
Powered by
Anyone know anything about `TypeError: 'output_dir...
# general
a
Anyone know anything about 
TypeError: 'output_dir' must be a string or None
that I’m seeing a bunch on CI, before I dig in?
h
Can you please post a link to the line in Travis log where this is happening?
a
h
And it looks the command we’re doing. Will try reproducing locally 
/Users/travis/build/pantsbuild/pants/build-support/pants_dev_deps.py2.venv/bin/python2.7 -u -c "import setuptools, tokenize;__file__='/private/var/folders/my/m6ynh3bn6tq06h7xr3js0z7r0000gn/T/pip-install-VCHu2H/grpcio/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d
Looking into the source code for Python 2.7 branch, I think the issue is it’s expecting bytes, rather than unicode. It’s not clear to me that we are passing unicode tho.. I also don’t see where we’re getting this code from / not sure we have control of it
a
i love distutils!!!!
😢 1
i'm mildly impressed because 
unixccompiler.py
explicitly passes in 
None
-- unless control is coming from somewhere else
h
@average-vr-56795 is this flaky or consistent?
a
Seems consistent, I’ve seen it on several branches
👍 1
My suspicion is that something changed either in the travis environment or in some dependency of grpcio or something
h
Agreed. Note that the 
OSX Build Engine (Py2)
shard worked for every build in master, so it appears this change is not from any of our commits, but is external https://travis-ci.org/pantsbuild/pants/builds
a
a
i was quite worried it was the big diff that removed python_dist() native toolchain support, phew
if it's not clear what specifically breaks it i can take a look into that and try to push a fix unless just a clean revert is appropriate
a
The thing that breaks it is apparently building the grpcio third party dep on that travis configuration… Would be nice to know the environmental thing that’s broken so we can maybe fix it, but if that’s not easy, some kind of revert would probably be worth thinking about…
h
a
at least it looks like they were testing it, and the test framework (kokoro?) was being screwy (unclear if that's a diversion)
w
so... i think there might be another possible workaround. i don't think we actually need that dep in core pants.
👍 2
i'll look into that.
h
Contrib failure for Stu’s PR. I can’t tell if this is a flaky network thing or genuine issue? https://travis-ci.org/pantsbuild/pants/jobs/485562483#L2234
w
looking
a
it's flaky
this is an old flake
w
that's network flakiness.
h
Wait one sec to restart!
I’ll open an issue
(We track network flaky)
w
i'm going to just merge.
👍 1
h
sgtm
a
i thought there was an issue!!! can't find it for some reason
h
Hm this is very similar but not the same
a
yeah
it might have just been discussed on slack
it's definitely on one of the post-its on my desk
h
I just added on to that ticket. They’re the same target, and both appear to be network flakiness. Also reclassified label from 
flaky-test
to 
network-flaky
👌 1
a
thanks!
h
For the record, issue goes all the way back to setuptools https://github.com/pypa/setuptools/issues/1653
a
Does that suggest we pull in a floating setuptools version which we could be constraining to an exact version somewhere?
w
the virtualenv in pantsbuild/pants might pin that. i know that the install script does.
5 Views
Open in Slack
PreviousNext
Powered by