A snag that a number of users have hit is that a default installation of IPython ignores whether you have a virtualenv active. I've heard this from a user I was talking to, and there are workarounds posted on the web:
This basically integrates that workaround so it's activated whenever you start system-installed IPython with a virtualenv active. It's not perfect, so a warning is printed suggesting that users install IPython in the virtualenv.
There's an argument that if we can't handle it perfectly, we should simply get users to install IPython again in the virtualenv. But I think that this solution is good enough in the vast majority of cases that practicality should beat purity. People use IPython as a quick and easy way to check things, so anything which requires extra work on their part to run it is not ideal.
Another workaround is to change the shebang to #!/usr/bin/env python, but virtualenv now defaults to --no-site-packages, which will leave IPython un-importable. Also, the shebang won't affect Windows users.
Add simple support for running inside a virtualenv.
Seems sensible to me, I suppose. I have always leaned towards instructing people to just use virtualenv correctly, in which event this would never come up, but that seems to be a pretty rare occurrence.
@fperez , I'd like your thoughts on this one before I proceed with it.
Mmh, what I don't really understand is, if these people are creating a virtualenv to install their other packages, what exactly prevents them from also installing ipython in there? I mean, either they want a virtualenv or they don't, and if they want one, they must populate it with the packages they want appearing in the venv, ipython being one of them...
I just fail to understand how ipython turns out to be in any way a special case regarding venv setup: we're not donig any special hackish sys.path manipulations ourselves, so we should be absolutely no different from any other python package that has an executable entry point, right? Doesn't sphinx-build have the exact same issues, or f2py, or the cython compiler call, or anything else that can be called as an executable, and where there's a conflict between the python used by the executable entry point and the library imports used by the virtualenv?
I do realize the need for practicality over purity, but this smacks me of crossing the line from practicality into flat out nasty hacks for the sake of helping people who are unwilling to do something as completely trivial as typing
python setup.py install
python setup.py develop
Neither of those seems so much to ask for, that we need to pollute our own code with an ugly workaround...
All those tools have the same issue, but they're all things that you make a definite plan to use in a particular project, so it makes sense to install them (they might be in a requirements file). IPython is, for many users, a much more ad-hoc tool - you might drop into it to check a method signature, as a better alternative to the plain Python shell. And if you've got 60 virtualenvs for different projects, you don't want to have to install IPython in each one to get that convenience. The fact that multiple users have come up with workarounds for this also argues for its importance.
Put another way: for many users - perhaps most non-scientific users - IPython is a handy convenience. Anything that makes it less convenient reduces its utility for them exponentially.
I don't think the workaround is that ugly: it's one extra method, which will be a no-op if you're running IPython the preferred way.
OK, I still don't like it, but I see the value in your argument. It seems @minrk was on a similar boat to me, not thrilled but willing to go along. Let's merge this for the sake of utility then, with a formal "not happy about it" from me.
Ultimately, I wish there was a cleaner solution for this overall problem at the python level itself, where its import/execution machinery was designed for clean isolation. But since that's not happening any time soon, off we go with the hacks.