Ipython: IPython installé dans virtualenv. AVERTISSEMENT "Veuillez installer IPython à l'intérieur du virtualtenv"

Essayez de les imprimer depuis IPython :

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

Merci @minrk. Ci-dessous les sorties :

Avant d'appeler IPython à partir de la ligne de commande, mon invite s'affiche correctement comme suit :
([name of virtual env]) [my regular prompt]

Ensuite, une fois que je suis dans 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 (?)

Si je quitte ma session IPython, mon invite s'affiche correctement comme :
([name of virtual env]) [my regular prompt]

Pour clarifier, quand je dis installation externe _, je veux dire une installation _pas * dans le virtualenv, et ne faisant pas non plus partie d'une installation système, mais une que j'ai incluse en haut de $PATH et de $LD_LIBRARY_PATH et que je sais fonctionne correctement.

Peut-être y a-t-il une variable d'environnement qui me manque et qui déroute IPython pour croire que j'utilise l'installation système et non l'installation externe que je veux utiliser en combinaison avec mon virtualenv et que j'inclus au début de PATH et LD_LIBRARY_PATH ?

qu'est-ce que vous obtenez avec head $(which ipython) ?

un de plus : sys.argv

Si sys.executable est erroné, les choses ont mal tourné avant que les packages Python ne soient chargés. C'est précisément ce qui se passerait si le système ipython était installé dans l'env au lieu d'un système (par exemple, si vous faisiez /usr/bin/ipython avec l'env actif, nous devrions tous nous attendre à ce qu'il se comporte mal).

Il est possible que le correctif soit aussi simple qu'un hash -r , pouvez-vous essayer ?

Merci @minrk. head $(which ipython) renvoie :

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

Et print sys.argv renvoie le chemin vers l'installation Python externe.

Exécuter hash -r depuis le terminal semble avoir fonctionné !

Je reçois maintenant un avertissement différent
WARNING: IPython History requires SQLite, your history will not be saved

ce qui est intéressant, car je ne reçois pas ce message si je désactive mon virtualenv et lance ipython à partir de l'installation externe.

Je suppose que c'est ce que tu as fait :

1. vous avez exécuté ipython et vu cet avertissement
2. vous avez installé ipython dans l'env
3. dans la même session shell, vous avez essayé d'exécuter à nouveau ipython

Voici les informations pertinentes et pourquoi hash -r l'a corrigé :

• Le chemin des commandes est mis en cache après que vous les avez appelées, de sorte qu'il ne recherche pas réellement votre PATH pour une commande donnée plus d'une fois dans une session shell.
• which n'a pas connaissance de ce cache, donc which ipython ne pointe pas nécessairement vers le ipython qui sera appelé s'il a déjà été appelé dans la session shell.
• hash -r réinitialise simplement ce cache, de sorte que which sera à nouveau exact.

Quant à sqlite, quel Python avez-vous utilisé pour le virtualenv ?

@minrk Oui, c'est exact ! Merci. J'utilise Python 2.7 x64

Avez-vous créé Python vous-même ? Si tel est le cas, vous devez vous assurer que libsqlite est présent et disponible lorsque vous compilez Python.

Merci @minrk. libsqlite semble être disponible pour l'IPython externe, c'est-à-dire celui que j'exécute lorsque je n'active pas l'environnement virtuel (bien que ce ne soit pas celui de l'installation du système, puisque j'ai modifié PATH et LD_LIBRARY_PATH pour inclure une installation externe en haut). Cela dit, je suppose qu'il est possible que l'IPython externe utilise libsqlite partir de l'installation du système (probablement à partir d'autres chemins dans LD_LIBRARY_PATH ). Cela serait-il possible?

Quoi qu'il en soit, merci encore pour toute votre aide. Le problème initial que j'ai signalé est résolu, nous pouvons donc fermer le ticket en toute sécurité.

c'est généralement un problème de temps de compilation - je pense que vous avez besoin des en-têtes, etc. (vous ne pouvez pas le résoudre sans recompiler Python)

J'ai défini le logiciel de gestion de profil .py sur Notebook, il n'a donc jamais fonctionné !
Ensuite, je le trouve !
Merci!