mikr/whatstyle

PyPI release

Closed this issue · 4 comments

Are you planning on releasing this to PyPI soon?

mikr commented

Thanks for reminding me. It is up now: whatstyle · PyPI.

Nice.

I've started setting it up to be included in openSUSE.

It seems so far that only clang and yapf are needed for the tests. I've added a few other runtime dependencies to the build and they didnt appear to be used.

https://build.opensuse.org/package/show/home:jayvdb:coala/python-whatstyle

The "Tumbleweed" is a rolling release, with clang8 (but others are available), and three test failures. Any hints you could give would be appreciated.

[   64s] ...
[   64s] ======================================================================
[   64s] FAIL: test_pathological_diffs (__main__.DiffTestCase)
[   64s] Assure that a diff of a file with a different indentation or
[   64s] ----------------------------------------------------------------------
[   64s] Traceback (most recent call last):
[   64s]   File "tests/test_whatstyle.py", line 146, in test_pathological_diffs
[   64s]     self.assertLess(dists[0], dists[2])
[   64s] AssertionError: 0 not less than 0
[   64s] 
[   64s] ======================================================================
[   64s] FAIL: test_nestedoption (__main__.OptioncomboTestCase)
[   64s] ----------------------------------------------------------------------
[   64s] Traceback (most recent call last):
[   64s]   File "tests/test_whatstyle.py", line 310, in test_nestedoption
[   64s]     self.assertEqual(len(res), 22)
[   64s] AssertionError: 30 != 22
[   64s] 
[   64s] ======================================================================
[   64s] FAIL: test_tabcombo (__main__.ParsehistoryTestCase)
[   64s] ----------------------------------------------------------------------
[   64s] Traceback (most recent call last):
[   64s]   File "tests/test_whatstyle.py", line 97, in test_tabcombo
[   64s]     self.assertEqual(len(history), 62)
[   64s] AssertionError: 70 != 62
[   64s] 
[   64s] ----------------------------------------------------------------------
[   64s] Ran 16 tests in 13.126s
[   64s] 
[   64s] FAILED (failures=3)
mikr commented

Thanks for writing the spec!
The test suite had to be pinned to precise version numbers of the respective code formatters. The Vagrantfile defines a Ubuntu 16.04 environment in which the test results were generated and then manually checked for correctness and saved as known good results against regression errors during development.
To create the known good results in a different environment without comparison one can delete the tests/examples//result_ directories and run the tests and then inspect the results by hand.
For simplicity you might of course simply choose not to run the tests for a rolling release.

Unfortunately, all distros update their code formatters periodically, bumping to major releases without much concern for stability, as they are considered dev tools. Maybe it would be useful to add a marker on the tests which are "fragile" based on the code formatter versions, so they can be de-selected ( e.g. pytest -k 'not fragile'), allowing the other tests to run continuously.