A recurring issue, which I've just added to the FAQ - a standard installation of IPython won't recognise when you're in a virtualenv. Various workarounds are showing up, but it would be good to work out of the box.
The root of the problem is that the installation sets the shebang line of ipython to #!/usr/bin/python. If it's #!/usr/bin/env python, virtualenvs work as expected. (I don't know what the status is on Windows)
A few possible ways to deal with this:
Mmh, how is this problem unique to us? If this is happening, then it happens to any python project that installs executable scripts. Granted, many python projects are indeed just libraries with minimal to no user-facing executable code, but still: nose, cython are two that immediately come to mind with this same situation.
How does everyone else handle this problem? I'm not claiming it's not an issue, just thinking that somebody out there must have figured this one out...
I think for most things, it makes sense to run it with the system Python, ignoring locally installed libraries (e.g. if I run a mercurial command, a virtualenv shouldn't interfere with it). I suspect nose has the same problem in a standard installation, and I've also run into it with sphinx-build.
OK, I figured it out. The solution (not just for IPython, but for installying any python package that has scripts in a virtualenv) is to do the build step separately:
./setup.py build --executable "/usr/bin/env python"
This sets the shebang line correctly once the scripts get installed.
Since this is standard distutils, I think we can actually close the issue here. Feel free to put this tip up on the faq, as it's certainly not very obvious. I had an inkling of the solution because I had a vague memory of being able to control that line years ago when I was building RPMs with distutils for a lab where I had a bunch of Fedora machines. But otherwise it's not easy to just stumble upon this solution.
Yes, this has never had anything to do with IPython, it's always affected all distutils-installed scripts, but IPython is often the only such script inherited into a virtualenv.
It should be considered a virtualenv bug that they don't patch the #! line of python scripts.
So it turns out we can set this without requiring the user to pass an extra command line argument (http://stackoverflow.com/a/1719991/434217), but it only works for distutils style 'scripts', not setuptools 'entry_points'. I've got a branch for that, and I'll look into it more closely for 0.13.
I'm reopening this and assigning it to myself on the grounds that I think we can improve on the current situation.
fyi, the debian packages already use env python as shebang for ipython since a while , but for the entry point script used in py3 I have found no other way than to sed the resulting scripts .
what I find weird, but probably is a distutils issue, is that the script is only created on install, not on build.
This also makes testing a bit more ackward as iptest3 is only created after installation.
I don't think we need special handling for the new venv behavior. That the system wide ipython is not importable with --no-site-packages is the expected (and likely wanted) behavior.
installing ipython in that venv with easy_install results in the correct shebang.
Fixed, as much as it's going to be for now, by PR #1388, so I'm closing this again.
A helpful tip for others on Linux who find the version of IPython shipped in the distro now fails with importerror. Virtualenv changed the default behaviour from --system-site-packages to --no-site-packages. For IPython this means that when you run it from a terminal where the virtualenv is in your path, it will not pick up the ipython libs. Either install IPython in your virtualenv, or make your virtualenv use the system-site-packages.
If your systemwide IPython is installed with a shebang line like #!/usr/bin/python (not #!/usr/bin/env python), it should basically work, even with the new default.
I like to use --system-site-packages anyway, because it's a pain to install things like numpy and matplotlib repeatedly.