FAIL: test_lex_many_tokens (__main__.LexBuildOptionTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "testlex.py", line 559, in test_lex_many_tokens self.assert_(pymodule_out_exists("manytab.pyo")) AssertionError: False is not true It looks like they're doing quite a fragile assumptions there.
*** Bug 459314 has been marked as a duplicate of this bug. ***
testlex.py has a total of 5 such files with .pyo. Either turn the optimisation (-O) for the compiling by testlex.py or remove all instances of the .pyo files. How do you enable the -O option? It works fine in distutils ecalss with python_enable_pyc and python_disable_pyc for and aft of src_test.
(In reply to comment #2) > testlex.py has a total of 5 such files with .pyo. Either turn the > optimisation (-O) for the compiling by testlex.py or remove all instances of > the .pyo files. > How do you enable the -O option? It works fine in distutils ecalss with > python_enable_pyc and python_disable_pyc for and aft of src_test. Think of pypy.
Q. How do you enable the -O option? A. Think of pypy yields tilt. You'd a thought this is 20 questions. Bugs to me are for reporting (sure), followed by fixing and closing. If you know how to do both, please get on with it.
I'm just saying that you don't understand the issue and try to get bug count down quick. And then I will have to re-open it since the tests will still fail.
*** Bug 514446 has been marked as a duplicate of this bug. ***
(In reply to Michał Górny from comment #5) > I'm just saying that you don't understand the issue and try to get bug count > down quick. And then I will have to re-open it since the tests will still > fail. I am just saying this is no time for lectures and exposing my lack of understanding. You have the capacity to figure this off your own bat and you don't. No-one else does either it seems. Subsequently 503094 has a small library of keyword and stable requests are left hanging off it. Also they do not warrant be held up over missing .pyo files in an over demanding testsuite. 13 Dec 2014; Ian Delaney <idella4@gentoo.org> ply-3.4-r1.ebuild: tests retricted, closes bug #458648, finally
According to some well informed users, the fix for this requires the use of PYTHONDONTWRITEBYTECODE. According to an established ebuild, this can be done like so; src_test() { # (unset) local -x PYTHONDONTWRITEBYTECODE or alternatively can be set to "0", being true. Sadly there is yet another flaw laying behind this once fixed. see $URL. The last comment by dabeaz gives mixed messages. Initially it implies the problem lies within the test file itself. The second throws everything wide open. What we end with is a report of a fix in the repo, yet no release of this package since then, and statements casting doubt over the integrity of core files. I would leave this resolved UPSTREAM since it is them that leave us with this, however in consultation with comrel I have been asked to re-assign this open. Timeout time set to 1 week makes it Christmas day~ I'll make it 6. After that the above fix already proven effective is set for commit to dev-python/ply-3.4-r1. This action has been discussed with and endorsed by pachos2 of comrel
As I have already pointed out, your 'fix' doesn't solve the issue with PyPy. And there is no other proper fix but removing the test since it doesn't serve any real purpose and relies on implementation details.
(In reply to Michał Górny from comment #9) > As I have already pointed out, your 'fix' doesn't solve the issue with PyPy. > And there is no other proper fix but removing the test since it doesn't > serve any real purpose and relies on implementation details. 1. It's not (only) 'my' fix. It's feedback from Arfrever, as is the bug filed by him. 2. You never pointed out. You hinted obliquely, and for all of us this was only ever 'obvious' or apparent to you and Arfrever. Arfrever as we all know cannot act on it 3. Why not drop pypy and allow a clear path for this fix to apply? 4. Perhaps you could supply a patch. On my part I have no disagreement with removing either the test(s) or support of pypy as a final solution. seding out a test or 2 is a fix I have done scores of times in testsuites in 'python herd'. pypy to my knowledge has a known user base of one and its 'need' or representation as a supporting python impl in packages in portage is random and arbitrary at best. What is required here is a resolution so the bug can be closed.
(In reply to Ian Delaney from comment #10) > (In reply to Michał Górny from comment #9) > > As I have already pointed out, your 'fix' doesn't solve the issue with PyPy. > > And there is no other proper fix but removing the test since it doesn't > > serve any real purpose and relies on implementation details. > > 3. Why not drop pypy and allow a clear path for this fix to apply? Well, maybe we should go further and drop the whole package! It is certainly the root cause of the issue. So let me repeat in bold: *tests* are broken, not the *package*, *PyPy* or the *ebuild*. So if you want to fix it, fix the tests. If you want to commit something random just to get bug count down, please just leave this bug open to people who actually care about improving things rather than pretending to fix bugs. And just to be clear: *fixing* bugs is about figuring out what's wrong. Not figuring out what happens to make the error message disappear, or what someone else did to make it disappear. It's about understanding the issue, and finding a proper resolution. > 4. Perhaps you could supply a patch. So to sum up, you come here, make noise, waste others' time and in the end someone else ends up fixing the bug? Sounds familiar.
Master Arfrever hath ycreated the proper fix: https://code.google.com/p/gentoo-progress/source/browse/overlays/progress/dev-python/ply/files/ply-3.5_pre20140101-tests.patch?r=5205
(In reply to Ian Delaney from comment #8) > I would leave this resolved UPSTREAM since it is them that leave us with > this, however in consultation with comrel I have been asked to re-assign > this open. > Timeout time set to 1 week makes it Christmas day~ I'll make it 6. After > that the above fix already proven effective is set for commit to > dev-python/ply-3.4-r1. > > This action has been discussed with and endorsed by pachos2 of comrel Respectfully, comrel has no say in this, other than helping you communicate with mgorny. If the tests are not fixed, this bug should remain open. There is no acceptable "timeout" after which we just decide to close it without resolving the issue. Restricting tests should not be treated as a resolution; the test suite is not so completely broken as to warrant that. It looks like Arfrever has helpfully supplied a patch; it might be wise to wait for upstream to review it.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #12) > Master Arfrever hath ycreated the proper fix: > https://code.google.com/p/gentoo-progress/source/browse/overlays/progress/ > dev-python/ply/files/ply-3.5_pre20140101-tests.patch?r=5205 It still doesn't cover the case of PYTHONDONTWRITEBYTECODE.
Thanks a lot for the patch Arfrever :) From my point of view, taking care this is only a testsuite bug, I would see no problem on waiting for upstream response (or for the next release) to get the patch introduced, as restricting tests is also a good option for now :/ But I am not even in python team, it's only an opinion :)
can you recheck with 3.9 version?
(In reply to Pacho Ramos from comment #16) > can you recheck with 3.9 version? It does work, sortof: >>> Source compiled. * Skipping make test/check due to ebuild restriction. >>> Test phase [disabled because of RESTRICT=test]: dev-python/ply-3.9 If I remove the RESTRICT=test: >>> Test phase: dev-python/ply-3.9 * python2_7: running distutils-r1_run_phase python_test .F..FFFF.................................. ====================================================================== FAIL: test_lex_many_tokens (__main__.LexBuildOptionTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "testlex.py", line 613, in test_lex_many_tokens self.assert_(pymodule_out_exists("manytab.pyo", 1)) AssertionError: False is not true ====================================================================== FAIL: test_lex_opt_alias (__main__.LexBuildOptionTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "testlex.py", line 546, in test_lex_opt_alias self.assert_(pymodule_out_exists("aliastab.pyo", 1)) AssertionError: False is not true ====================================================================== FAIL: test_lex_optimize (__main__.LexBuildOptionTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "testlex.py", line 395, in test_lex_optimize self.assert_(pymodule_out_exists("lextab.pyo", 1)) AssertionError: False is not true ====================================================================== FAIL: test_lex_optimize2 (__main__.LexBuildOptionTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "testlex.py", line 450, in test_lex_optimize2 self.assert_(pymodule_out_exists("opt2tab.pyo", 1)) AssertionError: False is not true ====================================================================== FAIL: test_lex_optimize3 (__main__.LexBuildOptionTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "testlex.py", line 500, in test_lex_optimize3 self.assert_(pymodule_out_exists("lexdir/sub/calctab.pyo", 1)) AssertionError: False is not true
It looks like newer versions of ply check for CPython for this particular set of tests. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e8ce88f4bf28e8ca3e58ccdce8168060ec7b37d9 commit e8ce88f4bf28e8ca3e58ccdce8168060ec7b37d9 Author: Mike Gilbert <floppym@gentoo.org> Date: Sat Jan 21 21:12:23 2017 -0500 dev-python/ply: clear PYTHONDONTWRITEBYTECODE for tests Bug: https://bugs.gentoo.org/458648 Package-Manager: Portage-2.3.3_p32, Repoman-2.3.1_p25 dev-python/ply/ply-3.6-r1.ebuild | 8 ++++---- dev-python/ply/ply-3.8.ebuild | 8 ++++---- dev-python/ply/ply-3.9.ebuild | 6 +++--- 3 files changed, 11 insertions(+), 11 deletions(-)
(In reply to Tobias Klausmann from comment #17) Thanks for retesting. My latest commit should take care of those failures.
I've just now tested with 3.6-r1, 3.8 and 3.9 and they all compile and test fine.
