Re: Error in build time tests (Was: numpy breaks nipy autopkgtest: No module named 'numpy.testing.decorators')
On Tue, Dec 08, 2020 at 09:44:51PM +0100, Andreas Tille wrote: > > https://github.com/nipy/nipy/issues/461 > > As far as I can see that's included into 0.4.3~rc1. If by "it" you mean requiring sympy older than the Debian one then yes. But the package evidently doesn't enforce this requirement. -- WBR, wRAR signature.asc Description: PGP signature
Re: Error in build time tests (Was: numpy breaks nipy autopkgtest: No module named 'numpy.testing.decorators')
FWIW those were reported "upstream" https://github.com/nipy/nipy/issues/466 unfortunately I had no time to look at them (again :-/) On Tue, 08 Dec 2020, Andreas Tille wrote: > Control: tags -1 pending > Control: tags -1 help > Hi, > I've updated nipy Git[1] to version 0.4.3~rc1 which solves the > originally reported issue. However, there are some remaining failures > in the build time test: -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: Error in build time tests (Was: numpy breaks nipy autopkgtest: No module named 'numpy.testing.decorators')
On Tue, Dec 08, 2020 at 11:11:27PM +0500, Andrey Rahmatullin wrote: > https://github.com/nipy/nipy/issues/461 As far as I can see that's included into 0.4.3~rc1. Yaroslav, would you mind commenting on this? It would be great to have some kind of 0.4.3~rc2 to get nipy fixed. Kind regards Andreas. -- http://fam-tille.de
Re: How to run unit tests?
On Tue, Dec 08, 2020 at 09:33:03PM +0100, Peter Wienemann wrote: > Dear Python experts, > > in trying to update the python-lark package [0] to the most recent upstream > version, an interesting issue regarding unit tests showed up [1]. Depending > on how one runs unit tests they either fail or not. Tried options are: > > 1. PYTHONWARNINGS=d pythonX -m unittest discover -v tests > 2. pythonX setup.py test > 3. pythonX -m tests Option 3 runs https://github.com/lark-parser/lark/blob/master/tests/__main__.py which mostly just runs unittest.main(). Option 2 seems to run the same file according to setup.py. I'm not familiar with unittests enough know the difference between options 1 and 3. You didn't explain what actual problems do you have, but https://github.com/lark-parser/lark/issues/792 suggests that some way you used was skipping some of the tests? > Upstream uses option 3 in its CI testing [2] and did not see any issues with > lark release 0.11.1. dh_auto_test seems to use option 2 by default (for the > pybuild build system). For autopkgtest I have chosen to use option 1. The > latter two options both fail for version 0.11.1. Which is good? > After applying a patch provided by upstream [3], also option 2 works but > option 1 still fails. Which is good or bad? I'm not sure. > Upstream suggested to change the way the (autopkgtest) tests are run [4]. So are you asking only about autopkgtests, not build-time tests? > Is there something like a general recommendation on what is the best way > to run Python unit tests? No (except "whatever the upstream CI runs"). -- WBR, wRAR signature.asc Description: PGP signature
How to run unit tests?
Dear Python experts, in trying to update the python-lark package [0] to the most recent upstream version, an interesting issue regarding unit tests showed up [1]. Depending on how one runs unit tests they either fail or not. Tried options are: 1. PYTHONWARNINGS=d pythonX -m unittest discover -v tests 2. pythonX setup.py test 3. pythonX -m tests Upstream uses option 3 in its CI testing [2] and did not see any issues with lark release 0.11.1. dh_auto_test seems to use option 2 by default (for the pybuild build system). For autopkgtest I have chosen to use option 1. The latter two options both fail for version 0.11.1. After applying a patch provided by upstream [3], also option 2 works but option 1 still fails. Upstream suggested to change the way the (autopkgtest) tests are run [4]. I am reluctant to do this without a better understanding of the differences between the above three options. Can anybody shed some light on the differences between them? Is there something like a general recommendation on what is the best way to run Python unit tests? Peter [0] https://salsa.debian.org/python-team/packages/python-lark [1] https://github.com/lark-parser/lark/issues/792 [2] https://github.com/lark-parser/lark/blob/0.11.1/.github/workflows/tests.yml#L28 [3] https://github.com/lark-parser/lark/pull/782 [4] https://github.com/lark-parser/lark/issues/792#issuecomment-739504664
Re: Error in build time tests (Was: numpy breaks nipy autopkgtest: No module named 'numpy.testing.decorators')
On Tue, Dec 08, 2020 at 07:02:22PM +0100, Andreas Tille wrote: > TypeError: unsupported operand type(s) for *: 'GreaterThan' and 'Add' Consider starting to use Google to find at least some info related to questions you ask. https://github.com/nipy/nipy/issues/461 -- WBR, wRAR signature.asc Description: PGP signature
Error in build time tests (Was: numpy breaks nipy autopkgtest: No module named 'numpy.testing.decorators')
Control: tags -1 pending Control: tags -1 help Hi, I've updated nipy Git[1] to version 0.4.3~rc1 which solves the originally reported issue. However, there are some remaining failures in the build time test: ... == ERROR: Failure: TypeError (unsupported operand type(s) for *: 'GreaterThan' and 'Add') -- Traceback (most recent call last): File "/usr/lib/python3/dist-packages/nose/failure.py", line 39, in runTest raise self.exc_val.with_traceback(self.tb) File "/usr/lib/python3/dist-packages/nose/loader.py", line 416, in loadTestsFromName module = self.importer.importFromPath( File "/usr/lib/python3/dist-packages/nose/importer.py", line 47, in importFromPath return self.importFromDir(dir_path, fqname) File "/usr/lib/python3/dist-packages/nose/importer.py", line 94, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/usr/lib/python3.9/imp.py", line 234, in load_module return load_source(name, filename, file) File "/usr/lib/python3.9/imp.py", line 171, in load_source module = _load(spec) File "", line 711, in _load File "", line 680, in _load_unlocked File "", line 790, in exec_module File "", line 228, in _call_with_frames_removed File "/build/nipy-0.4.3~rc1/.pybuild/cpython3_3.9_nipy/build/nipy/modalities/fmri/design.py", line 20, in from .hrf import glover File "/build/nipy-0.4.3~rc1/.pybuild/cpython3_3.9_nipy/build/nipy/modalities/fmri/hrf.py", line 123, in _gexpr = gamma_expr(5.4, 5.2) - 0.35 * gamma_expr(10.8, 7.35) File "/build/nipy-0.4.3~rc1/.pybuild/cpython3_3.9_nipy/build/nipy/modalities/fmri/hrf.py", line 106, in gamma_expr coef * ((T >= 0) * (T+1.0e-14))**(shape-1) TypeError: unsupported operand type(s) for *: 'GreaterThan' and 'Add' == ERROR: Failure: TypeError (unsupported operand type(s) for *: 'GreaterThan' and 'Add') -- ... (more of this type) ... == FAIL: Doctest: nipy.modalities.fmri.utils.convolve_functions -- Traceback (most recent call last): File "/usr/lib/python3.9/doctest.py", line 2204, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for nipy.modalities.fmri.utils.convolve_functions File "/build/nipy-0.4.3~rc1/.pybuild/cpython3_3.9_nipy/build/nipy/modalities/fmri/utils.py", line 494, in convolve_functions -- File "/build/nipy-0.4.3~rc1/.pybuild/cpython3_3.9_nipy/build/nipy/modalities/fmri/utils.py", line 533, in nipy.modalities.fmri.utils.convolve_functions Failed example: f1 = (t > 0) * (t < 1) Exception raised: Traceback (most recent call last): File "/usr/lib/python3.9/doctest.py", line 1336, in __run exec(compile(example.source, filename, "single", File "", line 1, in f1 = (t > 0) * (t < 1) TypeError: unsupported operand type(s) for *: 'StrictGreaterThan' and 'StrictLessThan' -- File "/build/nipy-0.4.3~rc1/.pybuild/cpython3_3.9_nipy/build/nipy/modalities/fmri/utils.py", line 538, in nipy.modalities.fmri.utils.convolve_functions Failed example: tri = convolve_functions(f1, f1, [0, 2], [0, 2], 1.0e-3, name='conv') Exception raised: Traceback (most recent call last): File "/usr/lib/python3.9/doctest.py", line 1336, in __run exec(compile(example.source, filename, "single", File "", line 1, in tri = convolve_functions(f1, f1, [0, 2], [0, 2], 1.0e-3, name='conv') NameError: name 'f1' is not defined -- ... -- File "/build/nipy-0.4.3~rc1/.pybuild/cpython3_3.9_nipy/build/nipy/modalities/fmri/utils.py", line 549, in nipy.modalities.fmri.utils.convolve_functions Failed example: y = ftri(x) Exception raised: Traceback (most recent call last): File "/usr/lib/python3.9/doctest.py", line 1336, in __run exec(compile(example.source, filename, "single", File "", line 1, in y = ftri(x) NameError: name 'ftri' is not defined -- File "/build/nipy-0.4.3~rc1/.pybuild/cpython3_3.9_nipy/build/nipy/modalities/fmri/utils.py", line 552, in nipy.modalities.fmri.utils.convolve_functions Failed example: x[np.argmax(y)] Exception raised: Traceback (most recent call last): File "/usr/lib/python3.9/doctest.py", line 1336, in __run exec(compile(exampl
Re: Python3.9 issue: '"yield from" can't be applied to "Condition"' (Was: Bug#976779: mypy FTBFS with only python 3.9)
On Tue, Dec 08, 2020 at 01:27:57PM +0100, Andreas Tille wrote: > test-data/samples/crawl.py:750: error: "yield from" can't be applied to > "Condition" > test-data/samples/crawl.py:772: error: "yield from" can't be applied to > "Semaphore" > test-data/samples/crawl.py:778: error: "yield from" can't be applied to > "Condition" https://github.com/python/mypy/pull/9375 Also https://github.com/python/mypy/issues/9761 -- WBR, wRAR signature.asc Description: PGP signature
Python3.9 issue: '"yield from" can't be applied to "Condition"' (Was: Bug#976779: mypy FTBFS with only python 3.9)
Control: tags -1 pending Control: tags -1 help On Mon, Dec 07, 2020 at 11:24:34PM +0200, Adrian Bunk wrote: > ... > #set -e; for v in 3.9; do > set -e; for v in 3.8; do \ > PATH=$PATH:/<>/debian/mypy/usr/bin/ python$v -m pytest -n > auto \ > -o testpaths=mypy/test -o python_files=test*.py \ > -k "not StubtestMiscUnit" \ > -o python_classes= -o python_functions=; \ > done > bash: line 2: python3.8: command not found I've dealt with this issue in Git. Unfortunately there is a test suite error remaining: set -e; for v in 3.9; do \ PATH=$PATH:/build/mypy-0.790/debian/mypy/usr/bin/ python$v -m pytest -n auto \ -o testpaths=mypy/test -o python_files=test*.py \ -k "not StubtestMiscUnit" \ -o python_classes= -o python_functions=; \ done = test session starts == platform linux -- Python 3.9.1rc1, pytest-4.6.11, py-1.9.0, pluggy-0.13.0 rootdir: /build/mypy-0.790, inifile: pytest.ini, testpaths: mypy/test plugins: cov-2.8.1, forked-1.3.0, xdist-1.32.0 gw0 I / gw1 I / gw2 I / gw3 I gw0 [266] / gw1 [266] / gw2 [266] / gw3 [266] ...s. [ 27%] ...F [ 54%] ssss [ 81%] ...s...s.[100%] === FAILURES === __ SamplesSuite.test_samples ___ [gw3] linux -- Python 3.9.1 /usr/bin/python3.9 Sample check failed - Captured stdout call - test-data/samples/crawl.py:750: error: "yield from" can't be applied to "Condition" test-data/samples/crawl.py:772: error: "yield from" can't be applied to "Semaphore" test-data/samples/crawl.py:778: error: "yield from" can't be applied to "Condition" Found 3 errors in 1 file (checked 1 source file) === 1 failed, 258 passed, 7 skipped in 81.97 seconds === Any hint would be welcome Andreas. -- http://fam-tille.de
