peterbrittain / asciimatics

A cross platform package to do curses-like operations, plus higher level APIs and widgets to create text UIs and ASCII art animations
Apache License 2.0
3.62k stars 237 forks source link

unit test failures on macos #327

Closed cltrudeau closed 2 years ago

cltrudeau commented 3 years ago

Describe the bug Hi Peter,

We chatted in the lobby a couple of months back and I finally got some time to attempt a fork for an MR. Before making changes I ran the tests and am getting three errors, all FileBrowser widget -- it appears to have something to do about a date assumption.

To Reproduce Run "nosetests" on a macos. Attempted with both FORCE_TTY on and off, fails in both cases

Expected behavior Unit tests pass

Screenshots Test output appended at end of ticket

System details (please complete the following information):

Additional context

$ pip freeze
alabaster==0.7.12
appveyor-artifacts @ git+https://github.com/peterbrittain/appveyor-artifacts.git@650f26569fc7e30165c6fa98581f95f17a7178b4
Babel==2.9.1
certifi==2021.5.30
charset-normalizer==2.0.4
coverage==5.5
coveralls==3.2.0
docopt==0.6.2
docutils==0.17.1
future==0.18.2
idna==3.2
imagesize==1.2.0
Jinja2==3.0.1
MarkupSafe==2.0.1
mock==4.0.3
nose==1.3.7
packaging==21.0
Pillow==6.2.2
pyfiglet==0.8.post1
Pygments==2.10.0
pyparsing==2.4.7
pytz==2021.1
requests==2.26.0
setuptools-scm==6.3.1
snowballstemmer==2.1.0
Sphinx==4.1.2
sphinxcontrib-applehelp==1.0.2
sphinxcontrib-devhelp==1.0.2
sphinxcontrib-htmlhelp==2.0.0
sphinxcontrib-jsmath==1.0.1
sphinxcontrib-qthelp==1.0.3
sphinxcontrib-serializinghtml==1.1.5
tomli==1.2.1
urllib3==1.22
wcwidth==0.2.5

$ FORCE_TTY=Y nosetests
.....................F.FF................................................
======================================================================
FAIL: Check FileBrowser widget works as expected.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/ctrudeau/s/py_vir_envs/PUR2/lib/python3.9/site-packages/mock/mock.py", line 1346, in patched
    return func(*newargs, **newkeywargs)
  File "/Users/ctrudeau/s/github/fork/asciimatics/tests/test_widgets.py", line 2022, in test_file_browser
    self.assert_canvas_equals(
  File "/Users/ctrudeau/s/github/fork/asciimatics/tests/test_widgets.py", line 264, in assert_canvas_equals
    self.assertEqual(output, expected)
AssertionError: '/   [65 chars]   1969-12-31\n|-+ Lnk Directo...      9K    1[301 chars]  \n' != '/   [65 chars]   1970-01-01\n|-+ Lnk Directo...      9K    1[301 chars]  \n'
  /                     Size Last modified
- |-+ A Directory         9K    1969-12-31
?                                 ^^  - ^
+ |-+ A Directory         9K    1970-01-01
?                                 ^^ +  ^
- |-+ Lnk Directo...      9K    1969-12-31
?                                 ^^  - ^
+ |-+ Lnk Directo...      9K    1970-01-01
?                                 ^^ +  ^
- |-- A File              9K    1969-12-31
?                                 ^^  - ^
+ |-- A File              9K    1970-01-01
?                                 ^^ +  ^
- |-- A Lnk -> A Tgt      9K    1969-12-31
?                                 ^^  - ^
+ |-- A Lnk -> A Tgt      9K    1970-01-01
?                                 ^^ +  ^
- |-- oööÖ.txt            9K    1969-12-31
?                                 ^^  - ^
+ |-- oööÖ.txt            9K    1970-01-01
?                                 ^^ +  ^

-------------------- >> begin captured logging << --------------------
asciimatics.widgets.utilities: DEBUG: Updating: file_list
asciimatics.widgets.utilities: DEBUG: Updating: file_list
--------------------- >> end captured logging << ---------------------

======================================================================
FAIL: Check FileBrowser widget copes with permissions error on stat.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/ctrudeau/s/py_vir_envs/PUR2/lib/python3.9/site-packages/mock/mock.py", line 1346, in patched
    return func(*newargs, **newkeywargs)
  File "/Users/ctrudeau/s/github/fork/asciimatics/tests/test_widgets.py", line 1932, in test_file_browser_stat_err
    self.assert_canvas_equals(
  File "/Users/ctrudeau/s/github/fork/asciimatics/tests/test_widgets.py", line 264, in assert_canvas_equals
    self.assertEqual(output, expected)
AssertionError: '/   [65 chars]   1969-12-31\n|-- A File               0    1[301 chars]  \n' != '/   [65 chars]   1970-01-01\n|-- A File               0    1[301 chars]  \n'
  /                     Size Last modified
- |-- A Directory          0    1969-12-31
?                                 ^^  - ^
+ |-- A Directory          0    1970-01-01
?                                 ^^ +  ^
- |-- A File               0    1969-12-31
?                                 ^^  - ^
+ |-- A File               0    1970-01-01
?                                 ^^ +  ^
- |-- A Lnk                0    1969-12-31
?                                 ^^  - ^
+ |-- A Lnk                0    1970-01-01
?                                 ^^ +  ^

-------------------- >> begin captured logging << --------------------
asciimatics.widgets.utilities: DEBUG: Updating: file_list
asciimatics.widgets.utilities: DEBUG: Updating: file_list
--------------------- >> end captured logging << ---------------------

======================================================================
FAIL: Check FileBrowser widget with a file_filter works as expected.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/ctrudeau/s/py_vir_envs/PUR2/lib/python3.9/site-packages/mock/mock.py", line 1346, in patched
    return func(*newargs, **newkeywargs)
  File "/Users/ctrudeau/s/github/fork/asciimatics/tests/test_widgets.py", line 2115, in test_file_filter
    self.assert_canvas_equals(
  File "/Users/ctrudeau/s/github/fork/asciimatics/tests/test_widgets.py", line 264, in assert_canvas_equals
    self.assertEqual(output, expected)
AssertionError: '/   [65 chars]   1969-12-31\n|-- hello.bmp           9K    1[301 chars]  \n' != '/   [65 chars]   1970-01-01\n|-- hello.bmp           9K    1[301 chars]  \n'
  /                     Size Last modified
- |-+ A Directory         9K    1969-12-31
?                                 ^^  - ^
+ |-+ A Directory         9K    1970-01-01
?                                 ^^ +  ^
- |-- hello.bmp           9K    1969-12-31
?                                 ^^  - ^
+ |-- hello.bmp           9K    1970-01-01
?                                 ^^ +  ^

-------------------- >> begin captured logging << --------------------
asciimatics.widgets.utilities: DEBUG: Updating: file_list
asciimatics.widgets.utilities: DEBUG: Updating: file_list
--------------------- >> end captured logging << ---------------------

----------------------------------------------------------------------
Ran 175 tests in 7.042s

FAILED (SKIP=1, failures=3)
peterbrittain commented 3 years ago

That's surprising. It would appear that Linux and MacOS use a different base time for their timestamps. These aren't important differences and are going to be tricky to solve in a cross-platform way. You can check by running:

from datetime import date date.fromtimestamp(0)

On my Linux box that returns datetime.date(1970, 1, 1). If MacOS returns something different, I suggest that we just skip the tests on MacOS platforms.

cltrudeau commented 3 years ago

I've been digging a bit, and it appears that macOS returns the epoch in the local time zone. This problem isn't just mac, but mac west of UTC. This can be fixed with a variable in the test setup. I'll include it in the coming PR.

peterbrittain commented 3 years ago

Thanks for digging into that!

cltrudeau commented 3 years ago

Yeah, well it was bugging me. I maintain a library on converting epochs and milli-epochs back and forth and I couldn't understand why macOS appeared to be returning a negative epoch value -- nothing comes before Jan 1, 1970 in the Unix world :)

peterbrittain commented 3 years ago

Any reason you didn't include this in that last PR?

cltrudeau commented 3 years ago

I had a PR that fixed this and something else but accidentally did it on my master branch. Looks like when I cleaned up the commit and put it on a feature branch it killed the PR without me realizing. I'll open another one from the feature branch.

peterbrittain commented 2 years ago

Fixed by the above PR.