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
pythonPackages.asciimatics: init at 1.10.0 #54404
Conversation
|
ab3dabe
to
dfe967f
Compare
Should I remove the checkInputs then? Also I notice that pytestrunner is actually part of setup_requires so that should be in buildInputs and not propagatedBuildInputs right? |
I think you can leave them in the possibility of a tarball being distributed.
See #54403 (review) |
dfe967f
to
01933b6
Compare
Tests now run, however they fail Here's the output log
It appears to have something to do with screen tests. Not sure if this is due to Nix build environment or something else. |
@CMCDragonkai Edited you comment there to use an expandable markdown thingy, since it can be harder to read the thread. |
Perhaps there's a missing system dependency needed? Curses or something? |
Try running these tests in |
@dotlambda How do I do that? |
I guess |
I think even then, wouldn't |
From the response of asciimatics, some of the tests are expected to fail due to them being pinned to an older Pillow version. |
Using |
Ok so there are 36 errors due to:
1 error due to:
There's 1 FAIL:
It might be that the last 1 FAIL is actually expected to fail due to incompatible Pillow version. While the 36 errors are due to some weird STDOUT issue. The When running on NixOS or nix-shell it just works without errors. However it appears when running the test here it fails. Here's one of the test failure locations: https://github.com/peterbrittain/asciimatics/blob/master/tests/test_effects.py#L48 Is there a way to step into a nix-build here, and simulate the same build environment and run that command? I have a feeling that this is because nix-build has a "non-standard terminal environment". |
I have discovered that running the tests without redirecting the STDOUT results in the tests succeeding in many of those failures. Of course there's still some other errors, but as we saw above, that could be due to Pillow. Whereas if you redirect the STDOUT of the tests to somewhere else, then the tests fail like before. The result of running the tests without redirecting STDOUT is:
I did this by using
This I think shows that these tests require a non-redirected STDOUT. As in a real tty to be used when running those tests as it is performing tests on the terminal using curses. |
We need a pty allocator/terminal emulator to run the asciimatics tests in an unattended manner. I want to try using expect first, but I'm not sure if it will work properly when it comes to curses test. @cleverca22 suggested libtsm as it actually simulates a full terminal, but hardly any documentation. |
There's no point in investing so much time in enabling the tests. We can still test functionality by hand. |
Alright. My research showed that using expect does work to some extent, but you need to setup the terminal information to be a proper emulator. See: https://github.com/dineshkummarc/expect-src/blob/master/example/term_expect for an example. However that will complicate this test setup significantly.
The above could work if all terminal info was setup, but without it, it results in an non-terminating error where it blocks on: Alternatively if someone knows how to use libtsm that could also be an option. Looks like there hasn't always been much work on test harnesses for TUI applications. I'll just disable tests for now and hope that dvc can make use of it. |
01933b6
to
37f6630
Compare
Done. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ran tests locally but they obviously will still fail because of the issues with pillow.
Though I think it should be fine.
Thanks a lot for your investigation on trying to run tests that need a pty emulator.
Your suggested setup could still be useful elsewhere in nixpkgs, and I will use this as a reference if the need arise.
@GrahamcOfBorg build python2.pkgs.asciimatics python3.pkgs.asciimatics |
Motivation for this change
Asciimatics is a package to help people create full-screen text UIs (from interactive forms to ASCII animations) on any platform.
This package only has a wheel on Pypi, and I don't understand how to execute its tests. So I don't have a specified checkPhase.
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)