BF: check for stdin/out/err to not be closed before checking for .isatty

[yarikoptic]

Closes #3267

TODOs:

• test
• try to figure out what change in our behavior lead to the benchmark to start failing after Aug 8 2018. See Need to guard is_interactive better #3267

[codecov]

Codecov Report

Merging #3268 into 0.11.x will decrease coverage by 11.45%.
The diff coverage is 55.55%.

@@             Coverage Diff             @@
##           0.11.x    #3268       +/-   ##
===========================================
- Coverage    90.8%   79.34%   -11.46%     
===========================================
  Files         252      263       +11     
  Lines       33016    40803     +7787     
===========================================
+ Hits        29980    32375     +2395     
- Misses       3036     8428     +5392

Impacted Files	Coverage Δ
datalad/tests/test_utils.py	88.27% <100%> (-8.12%)	⬇️
datalad/utils.py	73.52% <50%> (-14.01%)	⬇️
datalad/interface/tests/test_annotate_paths.py	60.96% <0%> (-39.04%)	⬇️
datalad/interface/tests/test_run_procedure.py	63.12% <0%> (-36.88%)	⬇️
datalad/tests/test_testrepos.py	63.15% <0%> (-36.85%)	⬇️
datalad/distribution/tests/test_subdataset.py	65.35% <0%> (-34.65%)	⬇️
datalad/plugin/tests/test_addurls.py	66.24% <0%> (-33.76%)	⬇️
datalad/interface/tests/test_run.py	66.92% <0%> (-32.93%)	⬇️
datalad/interface/run.py	67.3% <0%> (-32.7%)	⬇️
datalad/distribution/tests/test_update.py	68.02% <0%> (-31.98%)	⬇️
... and 65 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8b61e85...b5e0edb. Read the comment docs.

[yarikoptic]

oh hoh, .closed itself pukes if stdout is closed

$> python2 /tmp/1.py 
Traceback (most recent call last):
  File "/tmp/1.py", line 3, in <module>
    print(sys.stdout.closed)
ValueError: I/O operation on closed file

$> python3 /tmp/1.py 
Traceback (most recent call last):
  File "/tmp/1.py", line 3, in <module>
    print(sys.stdout.closed)
ValueError: I/O operation on closed file.

$> cat /tmp/1.py    
import sys; 
sys.stdout.close(); 
print(sys.stdout.closed)

so I think there is no way around try/except :-/

[kyleam]

I'm not sure that is_interactive is the spot to guard against a closed stream. If we conflate closed streams with the normal isatty() -> false, won't downstream code just fail when trying to work with the closed streams? By catching the exception (or otherwise swallowing it) in is_interactive, aren't we just delaying the issue?

[yarikoptic]

legit concern, but

• we do not close streams, so I do not think we should guard downstream "too much". If anything relevant is closed, I expect code to crash at the appropriate point.
• how probable is the situation? ATM we have only a single use-case - running benchmarks under asv. Note that no other errors emerge AFAIK -- just for is_interactive, which gets fixed here (and there would be follow up PR as well to monkey patch benchmarks setup)

PS just mentioned that I managed to submit it against master, although I think it is well worth 0.11.x. will rebase

[kyleam]

• we do not close streams, so I do not think we should guard downstream "too much". If anything relevant is closed, I expect code to crash at the appropriate point.

Agreed, my suggestion wasn't that we guard downstream. I think we should assume that the streams are open and let an exception be raised---including in is_interactive(). This patch is making is_interactive report "false" when the answer is really "neither/invalid question" (which the exception describes nicely).

• how probable is the situation? ATM we have only a single use-case - running benchmarks under asv. Note that no other errors emerge AFAIK -- just for is_interactive, which gets fixed here (and there would be follow up PR as well to monkey patch benchmarks setup)

I'd think not likely at all. Again, I'd say we should assume that std{in,out,err} are open. Which makes me think that this should be fixed upstream (why does asv result in stdin being closed?)---or at least make a more local, well-documented kludge outside of is_interactive().

But I won't push back more than that because I don't think it matters all that much in practice.

[yarikoptic]

Which makes me think that this should be fixed upstream (why does asv result in stdin being closed?)---or at least make a more local, well-documented kludge outside of is_interactive().

yeah, I was on a fence to either do the archaeological study on when it was introduced to asv... my argumentation in support of "it is ok" was that I think it should not be guaranteed that stdin is open. My wild guess is that it was intentional on their end to guarantee that no input should somehow be expected. That is why I also think thought it is ok for is_interactive to just return False in such a case. Hence

This patch is making is_interactive report "false" when the answer is really "neither/invalid question" (which the exception describes nicely).

could be argued or clarified in documentation - IMHO the main purpose is to detect when environment is interactive and thus all streams are open and tty. If something is not satisfying that -- it is just False. I do not see any advantage for is_interactive throwing an exception when environment clearly is not interactive.
While at it I even wondered if we shouldn't check if stderr is a tty. I think it should be ok to redirect stderr to a file while stdin/out interacting with the user... but I guess it is a separate issue/PR

Overall:

• let's check with upstream: is stdin "closed" intentionally? airspeed-velocity/asv#802
• I will push a slight tune up to is_interactive docstring describing its "resilience".

[yarikoptic]

appveyor fail - unrelated #3287
travis -- probably due to my data transfer from the server its connection was more flaky. restarted those

[kyleam]

appveyor fail - unrelated #3287

The error from 3287 doesn't appear in the failure here. The only failure I spot in that run is

Invoke-WebRequest : 503 Service Temporarily Unavailable
nginx/1.13.12
[...]

Looks unrelated in any case.