Test failures and docs don't build on Mac OS X Lion

[cdeil]

I have installed the latest ipython from github (f30a572) via python setup.py install --user.

There are a few test failures and the docs don't build:
http://dl.dropbox.com/u/4923986/bug_reports/ipython-tests.log
http://dl.dropbox.com/u/4923986/bug_reports/ipython-docs.log

Let me know if I should create separate tickets for some of these issues. It's hard for me to tell which are known and which are new. I know that the docs v3 problem wasn't there a few weeks ago.

Note that I am using iterm2 (http://www.iterm2.com/, Build 1.0.0.20110821) instead of the default Apple terminal, in case it matters.

[minrk]

Hm, it might matter that it's iTerm, and it might also be that you are using MacPorts Python (you are, right?).

The doc builds have always been fragile, but these test failures are new to me (I've been running the test suite pretty much daily on Lion with System Python and Terminal.app). Can you try running from regular Terminal and/or with iTerm and regular Python to try to isolate the problem?

[cdeil]

Yes, I was using Macports python (python27 @2.7.2_4 to be precise).

I did have another issue with ipython and iterm2 (using help with ? didn't work because TERM was set to "xterm" by default by iterm2), but I think it is unrelated to the test failures, because they also show up in Terminal.app (see below):
http://code.google.com/p/iterm2/issues/detail?id=1956

Here's the log from running the tests in Terminal.app with Macports python:
http://dl.dropbox.com/u/4923986/bug_reports/ipython-tests-terminalapp.log

And running the tests in Terminal.app with Apple Python
http://dl.dropbox.com/u/4923986/bug_reports/ipython-tests-terminalapp-systempython.log

Note that I did not re-install ipython with Apple Python, so I don't know if the second log is useful at all.

[minrk]

I think if you do a clean reinstall of IPython, the first failure (profile lists not matching) should go away. The pylab profile has been removed, and you may have a stale install (or simply build dir) where this file still exists. If you cleanup your IPython install and build/dist dirs, I would expect this one to go away.

The other failure is clearly encoding related, and thus might somehow have to do with the xterm setting. All the locale stuff is very confusing, and clearly IPython is making some assumption it shouldn't be. Have you seen any weird unicode behavior in IPython itself (printing unicode, or entering unicode literals)? It's possible this one is just an issue in the test suite itself.

What do you get for:

python -c 'import locale; print locale.getpreferredencoding()'

?

[takluyver]

Also, have you installed GNU readline? If not, you'll probably get a big warning about libedit when you start ipython, suggesting you do easy_install readline.

[minrk]

I believe macports Python is built with real readline.

[cdeil]

The first failure did go away after removing old ipython files.

Now two failures remain:

**********************************************************************
IPython test group: IPython.frontendFAIL: Test that multiline history skips empty line cells
FAIL: Test that multiline entries are replaced twice

Here's my locale encoding (both in iterm2.app and Terminal.app):

$ python -c 'import locale; print locale.getpreferredencoding()'
US-ASCII

Pasting unicode characters from the clipboard into the terminal or ipython doesn't work.
Actually I don't care for that functionality, but if you want to debug why it's not working, let me know how I can help.

Yes, Macports does install GNU readline:

$ port installed | grep readline
  py27-readline @6.2.2_0 (active)
  py32-readline @6.2.2_0 (active)
  readline @6.2.000_0 (active)

[minrk]

That's the issue right there. It's unusual to have an ASCII locale, which makes all unicode inputs invalid, and end up getting replaced by ?. We should do one of:

• not use unicode in this test
• skip this test if unicode is not supported
• perform the same (cast_bytes?) transform on the test output that we do on the input, so that unicode behavior is consistent, and not assumed to work.

[cdeil]

After updating to 825a832 and completely removing the previously installed ipython version the sphinx docs build now completes (with plenty of errors and warnings though):
https://dl.dropbox.com/u/4923986/bug_reports/2012-06-10/ipython-docs.txt

[minrk]

@cdeil - does this mean we should close the issue, or are you still having problems? (tons of errors/warnings are always expected when running sphinx, at least in my experience, I only care that it completes).

[cdeil]

The sphinx build does finish.

The two unicode-related test failures in IPython.frontend for which you already suggest several possible solutions above are still there.

[minrk]

Try PR #1996

[cdeil]

PR #1996 doesn't resolve the two IPython.frontend errors for me, and I get an extra error in IPython.parallel:
https://dl.dropbox.com/u/4923986/bug_reports/ipython-ascii-branch.txt

Now this is the first time I try a github pull request, here's what I did:

python -c 'import IPython; print IPython.__file__' # to find out where the old ipython is installed
rm -rv /Users/deil/Library/Python/2.7/lib/python/site-packages/ipython-0.1*
rm -rv /Users/deil/Library/Python/2.7/lib/python/site-packages/IPython
git clone https://github.com/minrk/ipython.git ipython_min
cd ipython_min
git checkout ascii
python setup.py install --user
cd /tmp
python -c 'import IPython; IPython.test()'

Is this the correct / recommended way?

It would be great if you can shortly describe in the ipython docs "How to test a pull request", a google search isn't super helpful, it seems the best way would have been to add your ipython repo as a remote, then fetch and change branch?

Also I'm not sure if it is necessary to remove the old ipython and if there is a better way to do it?

[minrk]

I didn't know we even had an IPython.test() function!

The easiest way to test a PR is with our test_pr script:

cd tools
python test_pr.py 1996

Which basically checks out master, does git merge from the PR branch, installs to a virtual-env, and runs 'iptest', the IPython testing command, all without touching your installed versions.

Also, you did not actually end up testing my branch, as evidenced by the fact that your test report identified itself as IPython 0.12 beta

[cdeil]

That is awesome that you have such a simple way to test pull requests.

Doesn't work out of the box for me:

$ cd tools
$ python test_pr.py 1996
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named nose
Usage: virtualenv [OPTIONS] DEST_DIR

virtualenv: error: no such option: --system-site-packages
Traceback (most recent call last):
  File "test_pr.py", line 259, in <module>
    test_pr(args.number, post_results=args.publish)
  File "test_pr.py", line 217, in test_pr
    setup()
  File "test_pr.py", line 64, in setup
    check_call(['virtualenv', '-p', py, '--system-site-packages', 'venv-%s' % py])
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 511, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['virtualenv', '-p', 'python2.7', '--system-site-packages', 'venv-python2.7']' returned non-zero exit status 2
$ virtualenv # tab complete
virtualenv      virtualenv-2.7  virtualenv-3.2  
$ nosetests # tab complete
nosetests      nosetests-2.7  nosetests-3.2  
$ python -c 'import nose'
$

I also was puzzled by the "0.12 beta" from your branch, I'm not sure exactly how the version number is generated by IPython, but the file I import (according to the timestamp) is the one I installed this morning when installing the version from your branch I think:

$ python -c 'import IPython; print IPython.__file__'
/Users/deil/Library/Python/2.7/lib/python/site-packages/IPython/__init__.pyc
$ ls -lh /Users/deil/Library/Python/2.7/lib/python/site-packages/IPython/__init__.py*
-rw-r--r--  1 deil  staff   2.1K Jun 21 09:47 /Users/deil/Library/Python/2.7/lib/python/site-packages/IPython/__init__.py
-rw-r--r--  1 deil  staff   1.3K Jun 21 09:57 /Users/deil/Library/Python/2.7/lib/python/site-packages/IPython/__init__.pyc

[takluyver]

On 21 June 2012 10:16, Christoph Deil
reply@reply.github.com
wrote:

virtualenv: error: no such option: --system-site-packages

I think that means you need a newer version of virtualenv. We haven't
spent much time accommodating old versions of things for test_pr.

[cdeil]

I did have virtualenv 1.6.4, now I have 1.7.1.2 which is pretty recent, still the test_pr script doesn't work:

$ virtualenv --version
1.7.1.2
$ python test_pr.py 1996
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named nose
Traceback (most recent call last):
  File "test_pr.py", line 259, in <module>
    test_pr(args.number, post_results=args.publish)
  File "test_pr.py", line 217, in test_pr
    setup()
  File "test_pr.py", line 64, in setup
    check_call(['virtualenv', '-p', py, '--system-site-packages', 'venv-%s' % py])
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 506, in check_call
    retcode = call(*popenargs, **kwargs)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 493, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 679, in __init__
    errread, errwrite)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 1249, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

I added print statements, the nose ImportError comes from line 42 when checking python2.6:

$ python2.6 -c 'import nose'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named nose
$ which python2.6
/opt/local/bin/python2.6

Maybe ImportError could be added the the except statement in line 44?

The OSError comes from trying to execute virtualenv -p python2.7 --system-site-packages venv-python2.7 which fails because Macports installs it at virtualenv-2.7 and my alias isn't defined in the subprocess:

$ alias virtualenv
alias virtualenv='virtualenv-2.7'
$ which virtualenv-2.7 
/opt/local/bin/virtualenv-2.7

After defining a symbolic link instead of the alias I can use your scripts to test the pull request, I have posted the results.
The test failures are still there and a few new ones also that probably are the result of how my virtualenv is created (I can post the shell log if it helps).

So I guess the problem never was an old virtualenv version.
If you can modify the test_pr script to automatically find virtualenv-2.7, that would be nice.

Thanks for all your help and patience!

[takluyver]

On 21 June 2012 13:36, Christoph Deil
reply@reply.github.com
wrote:

Maybe ImportError could be added the the except statement in line 44?

The ImportError is raised in a subprocess, and check_call turns the
non-0 exit status into a CalledProcessError. We could hide the
traceback, but it doesn't actually affect the function of the tests.

[fperez]

Sounds from the above this isn't really a bug we need to keep open, right?

[minrk]

There are real bugs here, and I believe they are fixed by PR #1996 (I was able to reproduce them in master but not in that PR). I asked @cdeil to confirm, but test_pr + virtualenv + readline + OS X hasn't been treating him well.

[fperez]

OK, let's then try to get #1996 in and we'll assume it helps here, unless proven otherwise (and a reopen would be fine then). Thanks!

[minrk]

Okay, I merged #1996, so we can reopen this or open a new issue if something else comes up.

[cdeil]

Thanks!

Now all tests pass with ipython master on my machine.
The sphinx doc build also completes: https://gist.github.com/2982303