Summary: | Version bump dev-python/ipython-0.13 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Matt Summers (RETIRED) <quantumsummers> |
Component: | Current packages | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | palexander, usefuljunk |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://ipython.org/ipython-doc/rel-0.13/whatsnew/version0.13.html | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | ebuild patch |
Description
Matt Summers (RETIRED)
![]() Created attachment 317450 [details, diff] ebuild patch Right. Note attempts to import one oct2py. New ebuild for it in improvise. Sadly it throws a spanner in the works, so my guess there'll be no rush to add it to portage. archtester ipython # ebuild ipython-0.13.ebuild clean test bails out at IPython.extensions.tests.test_cythonmagic.test_extlibs ... ok IPython.extensions.tests.test_octavemagic.test_octave_inline ... FAIL IPython.extensions.tests.test_octavemagic.test_octave_roundtrip ... FAIL IPython.extensions.tests.test_octavemagic.test_octave_cell_magic ... FAIL IPython.extensions.tests.test_octavemagic.test_octave_plot ... ^C The first time I've seen a python test do a hang. The newly introduced oct2py invites this otherwise untried test file. oct abbreviates octave, a 15 mb solid C C++ autotools package. oct2py presumably makes an interface to octave. At this stage it looks a lemon. It's own test suite misfires on 6 tests. Now have to await some responses from upstream to see what their view is. So; I copied the ipython-0.12-globalpath.patch -> ipython-0.13-globalpath.patch. Arfrever has done one already of course and he has made a patch that nicely captures all the first few sed statements do. Usually other way around. The middle one required its own sed statement because they switched from ' -> ". No need to repeat it here, available from the treasured progress any time. The test_octavemagic.py I have entered a delete but that's only if you have the oct2py installed which has octave as a dep. pypy gets left out in the Siberian snow from the PYTHON_USE_WITH dilemma. It likely would need a more advanced numpypy to make the grade anyway. archtester ipython # USE_PYTHON="2.6 2.7 3.1 3.2" ebuild ipython-0.13.ebuild clean test merge ------------------------------------------------------- all pass all tests. ------------------------------------------------------- >>> Original instance of package unmerged safely. * Compilation and optimization of Python modules for CPython 2.6 [ ok ] * Compilation and optimization of Python modules for CPython 2.7 [ ok ] * Compilation and optimization of Python modules for CPython 3.1 [ ok ] * Compilation and optimization of Python modules for CPython 3.2 [ ok ] >>> dev-python/ipython-0.13 merged. be quick to beat the crush If we want to add the Octave bits, it needs the dep on oct2py (which is not in portage) and h5py ( in the tree) . Details are here: http://ipython.org/ipython-doc/stable/config/extensions/octavemagic.html An additional USE might be handy to manage this if we ever want to add it. For now it should suffice as is. Thanks for testing Ian Not that it will ever become invoked, from an issue at ipython I filed for the test failures of octave, I have from the issue; stefanv commented; This is a regression in the latest version of oct2py. I'll mail the author. So ipython is good to go anyway. oct2py will benefit from the above, not gentoo I get the following error: changing mode of build-2.7/scripts-2.7/iptest from 644 to 755 * Building of dev-python/ipython-0.13 with CPython 3.2... python3.2 setup.py build -b build-3.2 Traceback (most recent call last): File "setup.py", line 61, in <module> from setupbase import target_update File "/var/tmp/portage/dev-python/ipython-0.13/work/ipython-0.13/setupbase.py", line 74, in <module> execfile(pjoin('IPython','core','release.py'), globals()) File "/var/tmp/portage/dev-python/ipython-0.13/work/ipython-0.13/setupbase.py", line 55, in execfile exec(compile(open(fname).read(), fname, "exec"), globs, locs) File "/usr/lib64/python3.2/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 4379: ordinal not in range(128) This seems to be a known issue: https://github.com/ipython/ipython/issues/2057 They haven't released the fixed one yet. I don't really plan to run it on Python3 - emerge automatically tries to compile for both 2.x and 3.x. Is there any way to get it to do so only for 2.x? (In reply to comment #4) > File "/usr/lib64/python3.2/encodings/ascii.py", line 26, in decode > return codecs.ascii_decode(input, self.errors)[0] > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 4379: > ordinal not in range(128) > > What is your locale set to (`eselect locale list` will tell you), the LANG env var? I suspect "C" or nothing. You need a unicode locale for python these days. > This seems to be a known issue: > > https://github.com/ipython/ipython/issues/2057 > > They haven't released the fixed one yet. > > I don't really plan to run it on Python3 - emerge automatically tries to > compile for both 2.x and 3.x. Is there any way to get it to do so only for > 2.x? Set only USE_PYTHON="2.7" in make.conf search for the Python Developers Guide or http://dev.gentoo.org/~quantumsummers/use_python_guide.xml This bug will be closed now, since ipython-0.13 is in the tree. If you need to bring another issue up, file a new bug. |