I have installed the latest stable version of IPython within a virtualenv created with the latest stable version of virtualenv on the latest Python 2.7 and I still got a warning saying that I should install IPython inside the virtualenv.
In case there are any doubts, I created a virtualenv and activated it with source [virtenv]/bin/activate
, then installed ipython with pip install ipython
. To make sure I was running the right ipython, I did which ipython
it correctly points to the ipython
binary within the virtual environment. Yet, when I call ipython
, I get the WARNING message
:
WARNING: Attempting to work in a virtualenv. If you encounter problems, please install IPython inside the virtualenv
.
Why do I get the warning?
Try printing these from inside IPython:
import os, sys, IPython
print os.environ['VIRTUAL_ENV']
print sys.executable
print IPython.__file__
print sys.path
Thanks @minrk. Below are the outputs:
Before I call IPython from the command line, my prompt correctly shows as:
([name of virtual env]) [my regular prompt]
Then, once I am in IPython:
print os.environ['VIRTUAL_ENV']
# correctly prints the path to the environment
print sys.executable
# Prints the external path to Python (?)
print IPython.__file__
# Prints the external path to the ipython installation's __init__.pyc (?)
print sys.path
# Prints the path to the site-packages folder from the virtualenv at the top.
# Then the bin path of the Python's external installation (?)
# Then some paths to individual packages from the external installation (?)
# Then the paths to individual packages from the virtualenv (and it misses the virtualenv's installation of IPython, ?)
# Then a few more paths to individual packages of the external installation (?)
# Finally the IPython from the external installation (?)
If I exit my IPython session, my prompt correctly shows as:
([name of virtual env]) [my regular prompt]
To clarify, when I say external installation_, I mean an installation _not* within the virtualenv, and not part of a system installation either, but one that I have included at the top of $PATH
and of $LD_LIBRARY_PATH
and that I know works correctly.
Perhaps there is an environment variable that I am missing and that is confusing IPython to believe that I am using the system installation and not the external installation that I want to use in combination with my virtualenv and that I include at the beginning of PATH
and LD_LIBRARY_PATH
?
what do you get with head $(which ipython)
?
one more: sys.argv
If sys.executable is wrong, then things went awry before any Python packages were loaded. This is precisely what would happen if the system ipython
was instead of one installed into the env (e.g. if you did /usr/bin/ipython
with the env active, which we should all expect to be badly behaved).
It's possible the fix is as simple as a hash -r
, can you try that?
Thanks @minrk. head $(which ipython)
returns:
#!/path_to_my_virtual_env/bin/python
# EASY-INSTALL-ENTRY-SCRIPT: 'ipython==0.13.1','console_scripts','ipython'
__requires__ = 'ipython==0.13.1'
import sys
from pkg_resources import load_entry_point
sys.exit(
load_entry_point('ipython==0.13.1', 'console_scripts', 'ipython')()
)
And print sys.argv
returns the path to the external Python installation.
Running hash -r
from the terminal seems to have worked!
I now get a different warning though
WARNING: IPython History requires SQLite, your history will not be saved
which is interesting, since I don't get this message if I deactivate my virtualenv and run ipython from the external installation.
I assume this is what you did:
ipython
and saw this warningHere's the relevant info, and why hash -r
fixed it:
which
is not aware of this cache, so which ipython
does not necessarily point to the ipython
that will be called if it has been called before in the shell session.hash -r
simply resets this cache, so that which
will be accurate once again.As for sqlite, what Python did you use for the virtualenv?
@minrk Yes, that's correct! Thanks. I am using Python 2.7 x64
Did you build Python yourself? If so, you need to make sure libsqlite is present and available when you compile Python.
Thanks @minrk. libsqlite
seems to be available to the external IPython, i.e. the one I run when I do not activate the virtual environment (although this is not the one from the system installation, since I have modified PATH
and LD_LIBRARY_PATH
to include an external installation at the top). That said, I guess that it's possible that the external IPython is using libsqlite
from the system installation (probably from other paths in LD_LIBRARY_PATH
). Would that be possible?
Either way, thanks again for all your help. The original issue I reported is solved, so we can safely close the ticket.
it's generally a compile time issue - I think you need the headers, etc. (you can't fix it without recompiling Python)
I set the .py profile executive software to Notebook,so it never did run!
Then ,I find it!
Thank you!
Most helpful comment
It's possible the fix is as simple as a
hash -r
, can you try that?