Repository navigation
Tests fail on MacOS #167
Description
The tests fail on MacOS
(and possibly on other *nix systems)
An exception is raised on access to attributes in termios.
When running normally, this code does not raise an exception. Not sure why pytest isn't happy with it... yet.
Doesn't appear to be isolated to pytest though... pfalcon/picotui#71
Since there's no usage (that we know of) of fixate on *nix systems, it's probably not worth chasing down, but I wanted to note it.
Activity
clint-lawrence commentedon Feb 23, 2023
I could be totally off the mark here, but could be a result of stdin/stdout being connected to a pipe rather than terminal
Check if stdin is a terminal before calling termios on it, because th…
josh-marshall-amp commentedon Jul 22, 2024
(cough) fix incoming
Merge pull request #198 from PyFixate/167-tests-fail-on-macos
jcollins1983 commentedon Jul 31, 2024
Not sure this issue should be closed (if we want to support *nix)...
The tests still don't pass on Mac without passing extra parameters to pytest; and doing that makes the output horrible.
tox -e pyon mac results inThe fix that was implemented will still evaluate the fileno(),
os.isatty(sys.stdin.fileno())Attempting to check if
stdinhas afilenoattribute instead of theisattycheck doesn't appear to make any difference.elif hasattr(sys.stdin, "fileno"):printing
sys.stdin.__dir__()shows that there is still afilenoattribute, but it looks like pytest checks for access of thefilenomethod and puts on the brakes. Pretty sure this is confirmed here pytest source codeAlso here in the same file:
So, I don't think (unless I'm missing something) that it's an easy thing to either check for
filenoorisatty.With a small tweak to the tox.ini to accept posargs for the pytest call,
tox -e py -- -s(tried because of this) and some hints in the pytest code, results in all thestdoutgoing to the terminal (to be expected since that's what it's supposed to do) except the tests pause at this point waiting for something to acknowledge the exceptionpressing enter allows the tests to continue, I think it's one of the
xfailmarked tests.Ending up with the tests running, and passing
Including the tests that I've got in my branch for the fxconfig duplicate prevention. Note: tests not finished yet. The weird thing is that the captures that I'm doing there actually work with
-swhich should stop all capture if I'm reading the docs correctly.At this point, I think I'm probably best to do my development and testing on a windows machine, since that's where it really matters for us.
jcollins1983 commentedon Jul 31, 2024
Also, @josh-marshall-amp suggested to me the other day on messenger
Doing this makes the tests run, however my tests that are using pytests capture fixture (capfd at this point, but I get the same (lack of) result with capsys) don't capture anything.
So I'm not convinced that this is the solution, it could be part of it though.
josh-marshall-amp commentedon Aug 2, 2024
Sorry @jcollins1983, missed this response while I was buried in the Important Task. I agree my hack doesn't fix it, I've actually run into the same problem, and I'll come back to this when I get some spare cycles. My motivation here is not just for my own running, but also to make it possible to run the tests in *nix CI. I'll reopen.