Ipython: IPython instalado no virtualenv. AVISO "Por favor, instale o IPython dentro do virtualtenv"

Tente imprimi-los de dentro do IPython:

import os, sys, IPython
print os.environ['VIRTUAL_ENV']
print sys.executable
print IPython.__file__
print sys.path

Obrigado @minrk. Abaixo estão as saídas:

Antes de chamar o IPython na linha de comando, meu prompt mostra corretamente como:
([name of virtual env]) [my regular prompt]

Então, uma vez que estou no 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 (?)

Se eu sair da minha sessão do IPython, meu prompt mostrará corretamente como:
([name of virtual env]) [my regular prompt]

Para esclarecer, quando digo instalação externa _, quero dizer uma instalação _não * dentro do virtualenv, e também não faz parte de uma instalação do sistema, mas uma que incluí no topo de $PATH e de $LD_LIBRARY_PATH e que eu sei funciona corretamente.

Talvez haja uma variável de ambiente que esteja faltando e que esteja confundindo o IPython para acreditar que estou usando a instalação do sistema e não a instalação externa que quero usar em combinação com meu virtualenv e que incluo no início de PATH e LD_LIBRARY_PATH ?

o que você ganha com head $(which ipython) ?

mais um: sys.argv

Se sys.executable estiver errado, as coisas deram errado antes que qualquer pacote Python fosse carregado. Isto é precisamente o que aconteceria se o sistema ipython fosse em vez de um instalado no env (por exemplo, se você fizesse /usr/bin/ipython com o env ativo, o que todos devemos esperar que seja mal comportado).

É possível que a correção seja tão simples quanto hash -r , você pode tentar isso?

Obrigado @minrk. head $(which ipython) retorna:

#!/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')()
)

E print sys.argv retorna o caminho para a instalação externa do Python.

A execução de hash -r a partir do terminal parece ter funcionado!

Agora recebo um aviso diferente
WARNING: IPython History requires SQLite, your history will not be saved

o que é interessante, já que não recebo essa mensagem se desativar meu virtualenv e executar o ipython a partir da instalação externa.

Eu suponho que isso é o que você fez:

1. você executou ipython e viu este aviso
2. você instalou o ipython no env
3. na mesma sessão do shell, você tentou executar o ipython novamente

Aqui estão as informações relevantes e por que hash -r corrigiu:

• O caminho dos comandos é armazenado em cache depois que você os chama, portanto, na verdade, ele não pesquisa seu PATH por um determinado comando mais de uma vez em uma sessão de shell.
• which não está ciente deste cache, então which ipython não necessariamente aponta para o ipython que será chamado se tiver sido chamado antes na sessão do shell.
• hash -r simplesmente redefine esse cache, para que which seja preciso novamente.

Quanto ao sqlite, qual Python você usou para o virtualenv?

@minrk Sim, está correto! Obrigado. Estou usando Python 2.7 x64

Você mesmo construiu o Python? Nesse caso, você precisa ter certeza de que libsqlite está presente e disponível ao compilar o Python.

Obrigado @minrk. libsqlite parece estar disponível para o IPython externo, ou seja, aquele que executo quando não ativo o ambiente virtual (embora este não seja o da instalação do sistema, pois modifiquei PATH e LD_LIBRARY_PATH para incluir uma instalação externa no topo). Dito isso, acho que é possível que o IPython externo esteja usando libsqlite da instalação do sistema (provavelmente de outros caminhos em LD_LIBRARY_PATH ). Isso seria possível?

De qualquer forma, obrigado novamente por toda a sua ajuda. O problema original que relatei foi resolvido, para que possamos fechar o ticket com segurança.

geralmente é um problema de tempo de compilação - acho que você precisa dos cabeçalhos, etc. (você não pode corrigi-lo sem recompilar o Python)

Eu configurei o software executivo de perfil .py para Notebook, então ele nunca foi executado!
Então, eu encontro!
Obrigado!