Created attachment 342728 [details] ebuild $ ebuild pyzmq-13.0.0.ebuild clean test ---------------------------------------------------------------------- Ran 168 tests in 17.378s OK (SKIP=24) NOTE: PYTHON_COMPAT=( python{2_6,2_7,3_1,3_2,3_3} pypy{1_9,2_0} ) pypy passes the whole test suite despite some deps not actually supporting pypy! pypy support re-introduced into this version bump. Firstly, require cffi to be keyworded by arm Secondly, the patch I have cloned requires upstream to get a pull request fully accepted and committed into 13.0.0 or mb 13.0.1 It has already been tested and appears a formality, and there's no rush for this
Why are you inroducing pypy? Does someone need it? Or is it just 'because we can'?
(In reply to comment #1) > Why are you inroducing pypy? Does someone need it? Or is it just 'because we > can'? eeeer, Why do you ask? I mean really, why do you ask? If push comes to shove, it's because we can. Why not introduce pypy, with a t? Why is pypy in the gentoo package list? Why do we support py2.5? Because it's there and against all logical expectations because there may be users who depend on it. Pypy differs in any direct comparison because it doesn't have the same history; it's not Cpython Have you actually read the upstream issue, or is your time simply too sparse? Let me, once again, spell it out to you. cffi has been made a hardcoded dep in this major version bump. Upstream did it again and made it a depend on a ghost of dep in the form of ctypes_configure authored by no less than fijal, a living breathing upstream pypy developer, with whom I have in fact long ago exchanged first hand in irc. It bears no bias towards pypy, in contrast to what appears to have forged its very being. Cpython itself is made to depend cffi to build the version bump, hence the keyword request for cffi. Upstream happily responded to my filing of this latest shamozzle in rapid fire time. I cloned the patch which itself doesn't even match the supposed state of the current core pyzmq 13.0.0 core files, which afai am concerned is a mere curiosity. It worked. To pypy or not to pypy, that is the question. Either way I'll live.
(In reply to comment #2) > (In reply to comment #1) > > Why are you inroducing pypy? Does someone need it? Or is it just 'because we > > can'? > > eeeer, Why do you ask? I mean really, why do you ask? I'm asking because you disabled tests. Which means that the package will 'support' pypy though nobody will actually be able to test if it works. > Why do we support py2.5? Because it's there and against all logical > expectations because there may be users who depend on it. Pypy differs in > any direct comparison because it doesn't have the same history; it's not > Cpython We support py2.5 as long as it works, and we can test it. If it doesn't or nobody can test it, we don't support it.
ah right, so largely my oversight here. if [[ ${EPYTHON} == python3* ]]; then is what I mostly had and used. the adding of pypy to the line was a late entry which I made on the basis of the deps of pyzmq mostly not having support for pypy, and on making the bug I hadn't realised I hadn't removed it, so fair question on your part in the light of this. An in fact it still offers reasonable ground to out pypy but for the fact that the testsuite once run is passed by pypy. Make of it what you will.
CFFI is not used on CPython, CPython uses the Cython backend in zmq.core. To test without installing: IFF CPython: python setup.py build_ext --inplace python setup.py test awaiting https://bugs.gentoo.org/show_bug.cgi?id=462506
I bumped the version in the tree, 13.1 passes tests ok on cpython 2.7 (with cffi installed). Haven't tested on pypy (which isn't in PYTHON_COMPAT anyway).
yes, since cffi does pertain only to pypy. This is a curly one. The pypy2.0 b2 comes with cffi inbuilt, which seemingly skirts a need for keywording of the separate package cffi. However, on letting pypy loose on the testsuite we get ERROR: Failure: ImportError (No module named gevent) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib64/pypy2.0/site-packages/nose/loader.py", line 413, in loadTestsFromName .................................................. pypy2_0/build/lib/zmq/green/poll.py", line 2, in <module> import gevent ImportError: No module named gevent indicating a) nosetests is playing up with pypy & b) gevent is in fact an rdep. NOTE this isn't a test fail, it's an import error triggered by nosetests. Save making a new bug over this I'll try keep an eye on https://bugs.pypy.org/issue1480
