Tests fail on MacOS

[jcollins1983]

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... https://github.com/pfalcon/picotui/issues/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.

[clint-lawrence]

I could be totally off the mark here, but could be a result of stdin/stdout being connected to a pipe rather than terminal

[josh-marshall-amp]

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.

(cough) fix incoming

[jcollins1983]

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 py on mac results in

The fix that was implemented will still evaluate the fileno(), os.isatty(sys.stdin.fileno())

Attempting to check if stdin has a fileno attribute instead of the isatty check doesn't appear to make any difference. elif hasattr(sys.stdin, "fileno"):

printing sys.stdin.__dir__() shows that there is still a fileno attribute, but it looks like pytest checks for access of the fileno method and puts on the brakes. Pretty sure this is confirmed here pytest source code

Also 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 fileno or isatty.

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 the stdout going 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 exception

pressing enter allows the tests to continue, I think it's one of the xfail marked 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 -s which 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]

Also, @josh-marshall-amp suggested to me the other day on messenger

Or catch the exception and just continue onward without the saving

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]

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.