-
Notifications
You must be signed in to change notification settings - Fork 395
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Patch: stdout wrapper breaks some subprocess calls #6
Comments
Google Code Info: |
Has this landed yet? It is by far the largest support issue we have in #windmill, which is good because it Google Code Info: |
I haven't had time to evaluate the patch yet. My time to work on nose is severely Google Code Info: |
hi even with this patch, if i have a test like: def sh(cmd, blast_log=None): and run with i get FFAIL: Doctest: t.shTraceback (most recent call last): File "/opt/src/python-nose/t/t.py", line 6, in t.sh Ran 1 test in 0.005s FAILED (failures=1) Google Code Info: |
I wonder if the patch is out of date and there is another _SpoofOut class somewhere Google Code Info: |
The bug exists both in doctest and in nose, so that's why the doctest example fails. The nose patch looks fine -- except that it doesn't include any tests. If this is going Google Code Info: |
yes doctest.py from stdlib defines its own _SpoofOut at the top of my code works for me. (i realize it's probably a bad idea for a general Google Code Info: |
Google Code Info: |
I really need this fixed, and posted to the mailing list today not knowing of this ticket. Is Thanks! Google Code Info: |
I bet the MultiProcessFile in plugintest has this issue as well... Google Code Info: |
Same issue here. In my case it is a "simple" unit test where I happens to launch a process with subprocess. The StringIO wrapper kills the test. All tests run fine with unittest. nosetests version 1.0.0 Google Code Info: |
I was able to bypass this problem with the following short/horrible monkeypatch in my test code: #monkey patch to get nose working with subprocess... That hack just treats all attempts at .fileno() access on a StringIO instance as if it were stdout that was wrapped. It worked ok for me, but it may need to get uglier to deal with stderr as well if it doesn't work for you. Google Code Info: |
@russ: Please show us this simple testcase, and how to make it fail. We'll add it as a test for nose. Google Code Info: |
@workitharder: This little file will crash with nose: import subprocess, sys Note that that little test can also be fixed by changing sys.stdout to sys.stdout, but you may not always comfortably have direct access to the Popen call that is handing sys.stdout around. Cleaner would be to simply have nose subclass StringIO and add a bogus .fileno() member that will play nicely with subprocess. I see that that is what the initial patch posted seemed to do. Google Code Info: |
Thanks. Google Code Info: |
@workitharder: I don't have a patch, and that nasty monkey patch is exactly that... nasty! It is unclear whether or not it will cause other problems, although it did seem to work for my case. In particular it very likely prevents the spawned subprocess outputs to what it thinks stdout is from getting captured by the StringIO wrapper in the parent. I have not tested this, though. Sorry - no time to work through nose to try and figure out a real patch, although I would like to help. First reason being that I just started looking at using nose today and have no clue of the nose architecture (eg: why is stdout wrapped with StringIO anyway). Secondly, a clean patch may not be possible due to subprocess's heavy use of file descriptors. Google Code Info: |
(Old?) patch: https://gist.github.com/1477878 |
I'm having the same issue with nose and subprocess. The monkeypatch works, but it shouldn't be necessary. |
A fine workaround outside nose is to replace check_call with check_output or Popen |
Currently nose uses StringIO directly as a stdout wrapper which works fine
99% of the time.
subprocess.Popen's default stdout is sys.stdout. subprocess assumes this is
a real filehandler and tends to check sys.stdout.fileno(). Since the method
doesn't exist, bad things happen.
Attached is a patch that removes the direct use of StringIO with a Buffer
class that has a fileno() method that returns 1 the way stdout normall does.
_SpoofOut has also been modified to provide this method.
I ran all the unittests, they all still pass.
Google Code Info:
Issue #: 290
Author: mikeal.rogers
Created On: 2009-09-08T00:29:05.000Z
Closed On:
The text was updated successfully, but these errors were encountered: