Obtenir pdb dans Emacs pour utiliser le processus Python à partir de virtualenv en cours

Question

Je suis en train de déboguer du code python dans emacs en utilisant pdb et d'obtenir quelques problèmes d'importation. Les dépendances sont installées dans l'un de mes environnements virtualenv personnalisés.

Pdb utilise obstinément/usr/bin/python et pas le processus python de mon virtualenv.

J'utilise virtualenv.el pour supporter la commutation au sein des milieux emacs et par l'intermédiaire des crochets de postactivate décrits dans

http://jesselegg.com/archives/2010/03/14/emacs-python-programmers-2-virtualenv-ipython-daemon-mode/

Cela fonctionne bien lors de l'exécution python-shell

>>> import sys 
>>> print sys.path 

Mx Cela montre à toutes mes bibliothèques virtualenv indiquant que le shell python est celui de mon virtualenv.

Ceci est cependant contredit par M-! quel python, qui donne /usr/bin/python

Est-ce que quelqu'un sait comment je peux dire à M-x pdb d'adopter le processus python du virtualenv actuellement actif?

Answer 1

python-shell utilise la variable python-default-interpreter pour déterminer l'interpréteur Python à utiliser. Lorsque la valeur de cette variable est cpython, les variables python-python-command et python-python-command-args sont consultées pour déterminer l'interpréteur et les arguments à utiliser. Ces deux variables sont manipulées par virtualenv.el pour définir l'environnement virtuel actuel. Lorsque vous utilisez la commande python-shell, elle utilise vos environnements virtuels sans problème.

Mais, quand vous faites M-!python, vous n'utilisez pas les variables python-python-command et python-python-command-args. Il utilise donc les outils python qu'il trouve sur votre chemin.

Lorsque vous appelez M-xpdb, il utilise gud-pdb-command-name comme outil pdb par défaut. Pour redéfinir cette variable, chaque fois que vous activez un environnement, vous pouvez faire quelque chose comme ceci:

(defadvice virtualenv-activate (after virtual-pdb) 
    (custom-set-variables 
    '(gud-pdb-command-name 
     (concat virtualenv-active "/bin/pdb")))) 

(ad-activate 'virtualenv-activate) 

Pour avoir pdb dans votre environnement virtuel, procédez comme suit:

cp /usr/bin/pdb /path/to/virtual/env/bin 

Vous pouvez alors modifier la première ligne de/chemin/vers/virtuel/env/bin/pdb Souhaitée:

#! /usr/bin/env python 

réactiver votre env et PDB devrait maintenant utiliser votre python virtualenv au lieu du python système.

Answer 2

Invoke pdb comme ceci:

python -m pdb myscript.py 

Au lieu de

pdb myscript.py 

Answer 3

Peut-être, votre commande pdb est liée à une certaine version spécifique.

$ ls -ald /usr/bin/pdb 
lrwxrwxrwx 1 root root 6 Jun 2 23:02 /usr/bin/pdb -> pdb2.6 

Ensuite, regardez la première ligne de pdb2.6. Il contient

#! /usr/bin/python2.6 

C'est pourquoi pdb est têtu et semble toujours fonctionner sous une version spécifique de Python. Parce que c'est vraiment! En fait, ce genre de dépendance a du sens pour un logiciel comme un débogueur symbolique.

J'ai compilé python2.7 à partir de sources et pdb n'est pas là, apparemment. Après un examen minutieux, j'ai trouvé pdb.py pour python-2.7, sous le dossier lib. J'ai ensuite créé des liens symboliques à lui, pour des raisons pratiques:

$ cd /opt/python-dev ##-- this is where I installed from sources 
$ cd bin 
$ sudo ln -s ../lib/python2.7/pdb.py pdb2.7 
$ sudo ln -s pdb2.7 pdb 

Observons maintenant la première ligne de pdb2.7. Il se lit comme suit:

#! /usr/bin/env python 

... qui semble meilleur que la version précédente. Cela signifie que pdb sera lancé sous le Python actuel que vous avez défini dans votre environnement, quel qu'il soit, au lieu de tout codé en dur, comme /usr/bin/python ou /usr/bin/python2.6 sont. Bon à savoir!

J'ai aussi enlevé pdb et pdb2.6 de fichiers système, une fois que je préfère développer/debug à l'intérieur virtualenv. En faisant cela, je ne serai pas attrapé à nouveau par le même tour.

J'espère que ça aide.