Repository navigation
Travis doesn't like 0.12.1 #322
Description
Activity
Seems like a conflict with py.test or whatever
_pytestis?run()works generally on Travis as per our own Travis setup, eg: https://travis-ci.org/pyinvoke/invoke/jobs/107682850My 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_filenowill fix the issue. Thanks!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, theDontReadFromInputclass which is being slotted in as a fakesys.stdinunder thecapsysplugin. 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 anIOError("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.)
For now I'm "fixing" this by documenting and checking for a
Falsevalue passed torun(in_stream=...)(sinceNoneis already "taken" and stands for "usesys.stdin"). WhenFalseis 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).
Seems like that initial solution is working OK for now; it'll be out in 0.20, soon.
From https://travis-ci.org/datakortet/dk-tasklib/builds/107382354
Command being executed:
ctx.run("rm -rf build/{directory}/*".format(directory=directory))