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

Travis doesn't like 0.12.1 #322

Closed
thebjorn opened this Issue Feb 6, 2016 · 4 comments

Comments

Projects
None yet
2 participants
@thebjorn

thebjorn commented Feb 6, 2016

From https://travis-ci.org/datakortet/dk-tasklib/builds/107382354

Command being executed:

ctx.run("rm -rf build/{directory}/*".format(directory=directory))

        # If any exceptions appeared inside the threads, raise them now as an
        # aggregate exception object.
        if exceptions:
>           raise ThreadException(exceptions)
E           ThreadException: 
E           Saw 1 exceptions within threads (ValueError):
E           
E           
E           Thread args: {'kwargs': {'echo': None,
E                       'input_': <_pytest.capture.DontReadFromInput instance at 0x7fbb97779638>,
E                       'output': <_pytest.capture.EncodedFile object at 0x7fbb97774c10>},
E            'target': <bound method Local.handle_stdin of <invoke.runners.Local object at 0x7fbb96c55650>>}
E           
E           Traceback (most recent call last):
E           
E             File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/invoke/runners.py", line 851, in run
E               super(_IOThread, self).run()
E           
E             File "/opt/python/2.7.9/lib/python2.7/threading.py", line 763, in run
E               self.__target(*self.__args, **self.__kwargs)
E           
E             File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/invoke/runners.py", line 449, in handle_stdin
E               if ready_for_reading(input_):
E           
E             File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/invoke/platform.py", line 140, in ready_for_reading
E               if not has_fileno(input_):
E           
E             File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/invoke/util.py", line 61, in has_fileno
E               return isinstance(stream.fileno(), int)
E           
E             File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/_pytest/capture.py", line 438, in fileno
E               raise ValueError("redirected Stdin is pseudofile, has no fileno()")
E           
[1mE           ValueError: redirected Stdin is pseudofile, has no fileno()


@bitprophet

This comment has been minimized.

Member

bitprophet commented Feb 8, 2016

Seems like a conflict with py.test or whatever _pytest is? run() works generally on Travis as per our own Travis setup, eg: https://travis-ci.org/pyinvoke/invoke/jobs/107682850

My guess is our fileno detection is being thrown off by whatever that inner module of yours is doing. IIRC we try to capture only some specific exceptions and allow others to raise for just this kind of thing, so we may need to expand that.

I'm just triaging right now so can't dig, but feel free to dig on your own to see if a tweak to invoke.util.has_fileno will fix the issue. Thanks!

@bitprophet

This comment has been minimized.

Member

bitprophet commented Jun 26, 2017

Think I'm encountering a wrinkle of this same problem while attempting to port some of my test suites (including Fabric 2's which is Invoke based) to a pytest runner.

The issue in my case is from the same part of _pytest.capture, the DontReadFromInput class which is being slotted in as a fake sys.stdin under the capsys plugin. Specifically I'm having the issue on .read() instead of .fileno() (possibly due to changes in Invoke's stream handling post-0.12, not clear.) Shows up as an IOError("reading from stdin while output is captured").

Either way I suspect the least-awful option is a more generic "if stdin seems hard to read from, just don't bother" behavior...I don't think any test-oriented use of Invoke truly wants to be reading from stdin; and the fact that in my case, under a nose-based runner, things ran fine - is more a coincidence than anything.

That might also help avoid the perennial issues surrounding headless/detached execution, such as #425 (though I believe most of these have been finally squashed.)

@bitprophet

This comment has been minimized.

Member

bitprophet commented Jun 27, 2017

For now I'm "fixing" this by documenting and checking for a False value passed to run(in_stream=...) (since None is already "taken" and stands for "use sys.stdin"). When False is seen it is interpreted to mean "don't even spin up the stdin-handling thread at all".

Still leaves the autoresponding functionality in place (that runs in its own thread) and completely sidesteps any possible stdin related issues; is relatively easy to configure globally per project; etc.

Not closing this just yet because I may end up having to tweak it further or decide it's best made its own separate option (e.g. it's hard to set this via an env var because those don't really "do" bools, especially not for this style of multi-type option).

bitprophet added a commit that referenced this issue Jul 13, 2017

@bitprophet

This comment has been minimized.

Member

bitprophet commented Jul 27, 2017

Seems like that initial solution is working OK for now; it'll be out in 0.20, soon.

@bitprophet bitprophet closed this Jul 27, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment