Piping pantsd stdout doesn't work when running in Python 3.8

[stuhood]

./pants --pantsd list :: > $file works in 3.6/3.7 but not 3.8, in the example repo and at least one consumer repo.

[benjyw]

I can't reproduce this in the example repo. What demonstrates this?

[stuhood]

I think that that might mean it is specific to our own repo then. Thanks for confirming!

[benjyw]

We should still get to the bottom of this, no? In our repo I can see

$ ./pants --pantsd list src/python/:: > /tmp/foo
19:43:12 [INFO] initializing pantsd...
19:43:13 [INFO] pantsd initialized.

hanging forever, but it works if pantsd was already running, and it doesn't hang without the redirect. I see the same phenomenon if I pipe to less instead of redirect to a file. If I ctrl-c out then I see /tmp/foo has the content I expect.

Is that the phenomenon this ticket was opened for?

[stuhood]

Yes, that.

[benjyw]

OK, so I can repro this on Python 3.8 but not Python 3.7. Interesting.

[benjyw]

I can repro this on Python 3.8 (but not 3.6 or 3.7) in the example repo. So I think we have to say that 3.8 just isn't supported yet for running Pants?

[Eric-Arellano]

So I think we have to say that 3.8 just isn't supported yet for running Pants?

Note that we don't yet test 3.8 in CI.

[stuhood]

Mmm... I think that this also extends to integration tests that attempt to run pantsd. Many PantsRunIntegrationTests (which will use pantsd under the hood by default) hang under 3.8.

[gshuflin]

I can't reproduce this in the example repo:

at 14:29:07 ➤ ./pants --pantsd list :: > /tmp/file
at 14:29:13 ➤ cat /tmp/file 
//:ansicolors
//:protobuf
//:requirements.txt
//:setuptools
//:translate
helloworld:config
helloworld:config_file
helloworld:helloworld
helloworld:helloworld-awslambda
helloworld:helloworld_py2
helloworld/greet:greet
helloworld/greet:tests
helloworld/greet_py2:greet_py2
helloworld/util:config_loader_test_data
helloworld/util:tests
helloworld/util:util
helloworld/util/proto:proto
at 14:29:15 ➤ python --version
Python 3.8.5

Is it possible that the bug only manifests itself with a specific patch version of 3.8?

[benjyw]

python --version may not prove that ./pants is running 3.8. Try hand-editing ./pants to force it to run on 3.8.

[gshuflin]

python --version may not prove that ./pants is running 3.8. Try hand-editing ./pants to force it to run on 3.8.

I explicitly set the PYTHON environment variable to /usr/bin/python3.8 on my system and confirmed that ./pants is using that specific binary path, and still couldn't reproduce. Is it possible that this python 3.8 wierdness only manifests itself on a mac, and not linux? Also what is the behavior that pants does do in the case where you can reproduce it?

[benjyw]

Huh, I can no longer reproduce this on a mac either. I think we can close this for now, and reopen if we see more reports of this in the wild.

[stuhood]

python --version may not prove that ./pants is running 3.8. Try hand-editing ./pants to force it to run on 3.8.

I explicitly set the PYTHON environment variable to /usr/bin/python3.8 on my system and confirmed that ./pants is using that specific binary path, and still couldn't reproduce. Is it possible that this python 3.8 wierdness only manifests itself on a mac, and not linux? Also what is the behavior that pants does do in the case where you can reproduce it?

The relevant env var is PY:

pants/build-support/virtualenv

Lines 14 to 19 in 8f4e398

	# Locate the binary's path to log to user or die gracefully if not found.
	if command -v "${PY}" >/dev/null; then
	PY="$(command -v "${PY}")"
	else
	die "No ${PY} interpreter found on the path. Python will not work!"
	fi

The repro also seems to have changed a little bit: the following hangs:

cat <(PY=python3.8 ./pants list 3rdparty/::)

[stuhood]

Ok, false alarm... the cat <(./pants list 3rdparty/::) case is a separate issue that has been open a while: #5510, and it repros on any python version. So yea, it does appear that this particular issue is resolved.