Obtenir pdb dans Emacs à utiliser le procédé Python de virtualenv en cours

Question

Je suis le débogage du code python dans emacs en utilisant pdb et obtenir des problèmes d'importation. Les dépendances sont installées dans l'un de mes environnements bespoked virtualenv.

PDB utilise obstinément / usr / bin / python et non le processus de python de mon virtualenv.

J'utilise virtualenv.el à commutation de support à l'intérieur d'environnements 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 M-x

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

Cela souligne toutes mes bibliothèques virtualenv indiquant que le shell python est celle de mon virtualenv.

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

Quelqu'un sait comment je peux dire M-x pdb d'adopter le processus de python de la virtualenv active?

Answer 1

python-shell utilise python-default-interpreter variable pour déterminer quel interpréteur python à utiliser. Lorsque la valeur de cette variable est cpython, les variables python-python-command et python-python-command-args sont consultés pour déterminer l'interprète et les arguments à utiliser. Ces deux variables sont manipulées par virtualenv.el pour définir l'environnement virtuel actuel.

Ainsi, lorsque vous utilisez la commande python-shell, il utilise vos environnements virtuels sans aucun problème.

Mais, quand vous faites M - python, vous n'êtes pas en utilisant les variables python-python-command et python-python-command-args. Ainsi, il utilise les outils de python qu'il trouve dans votre chemin.

Lorsque vous appelez M-x pdb utilise GUD-pdb-commande nom comme l'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

Ensuite, modifiez la première ligne de / chemin / vers / virtuel / env / bin / pdb avoir:

#! /usr/bin/env python

Réactiver votre env et PDB doivent 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 pdb commande 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

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

#! /usr/bin/python2.6

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

J'ai compilé python2.7 de sources et pdb est pas là, apparemment. Après un certain contrôle, j'ai trouvé pdb.py de python-2.7, dans le dossier lib. Je l'ai ensuite créé des liens symboliques à elle, 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

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

#! /usr/bin/env python

... qui semble mieux que la version précédente. Cela signifie essentiellement que pdb sera lancé sous le Python courant que vous avez défini dans votre environnement, quoi que ce soit, au lieu de quoi que ce soit hardcoded, comme / usr / bin / python ou / usr / bin /python2.6 sont. Bon à savoir!

Je l'ai également supprimé pdb et pdb2.6 à partir 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 pris de nouveau par le même tour.

J'espère que ça aide.