Obteniendo pdb en Emacs para usar el proceso de Python desde el archivo virtualenv actual

Question

Estoy depurando algún código python en emacs usando pdb y obteniendo algunos problemas de importación. Las dependencias se instalan en uno de mis entornos virtualenv personalizados.

Pdb utiliza tercamente/usr/bin/python y no el proceso de python de mi virtualenv.

utilizo virtualenv.el para soportar la conmutación de los ambientes dentro de emacs y a través de los ganchos postactivate descritos en

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

Esto funciona bien cuando se ejecuta Mx pitón-shell

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

Este puntos a todas mis bibliotecas Virtualenv que indican que el Python-shell es el de mi virtualenv.

Sin embargo, esto es contradicho por M-! qué python, que da /usr/bin/python

¿Alguien sabe cómo puedo decirle a M-x pdb que adopte el proceso de python del virtualenv actualmente activo?

Answer 1

python-shell usa la variable python-default-interpreter para determinar qué intérprete de python usar. Cuando el valor de esta variable es cpython, se consultan las variables python-python-command y python-python-command-args para determinar el intérprete y los argumentos a usar. Esas dos variables son manipuladas por virtualenv.el para establecer el entorno virtual actual.

Por lo tanto, cuando usa el comando python-shell, utiliza sus entornos virtuales sin ningún problema.

Pero, cuando lo haga M-!python, no está utilizando las variables python-python-command y python-python-command-args. Entonces usa las herramientas de Python que encuentra en su camino.

Cuando llama a M-xpdb usa gud-pdb-command-name como la herramienta pdb predeterminada. Para volver a definir esta variable, cada vez que se active un entorno, que podría hacer algo como esto:

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

(ad-activate 'virtualenv-activate) 

Tener AP en su entorno virtual, haga lo siguiente:

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

luego editar la primera línea de/ruta/a// env/bin/AP virtual para tener:

#! /usr/bin/env python 

reactivar su env y el AP ahora debe usar su pitón virtualenv en lugar de la pitón de todo el sistema.

Answer 2

invocación de AP como esto:

python -m pdb myscript.py 

En lugar de

pdb myscript.py 

Answer 3

Posiblemente, su AP comando está ligado a una versión específica.

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

Luego, observe la primera línea de pdb2.6. Contiene

#! /usr/bin/python2.6 

Esta es la razón por AP es terco y siempre parece que se ejecute en una versión específica de Python. Porque realmente es! En realidad, este tipo de dependencia tiene sentido para un software como un depurador simbólico.

He compilado python2.7 de las fuentes y pdb no está allí, al parecer. Después de un examen minucioso, encontré pdb.py para python-2.7, bajo la carpeta lib. continuación, he creado algunos enlaces simbólicos a ella, por conveniencia:

$ 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 

observamos ahora la primera línea de pdb2.7. Se lee:

#! /usr/bin/env python 

... que se ve mejor que la versión anterior. Básicamente significa que pdb se lanzará bajo el Python actual que haya definido en su entorno, sea lo que sea, en lugar de cualquier cosa codificada, como /usr/bin/python o /usr/bin/python2.6. ¡Bueno saber!

También he quitado AP y pdb2.6 de archivos del sistema, una vez que prefiero para desarrollar/depuración dentro virtualenv. Al hacer eso, no seré atrapado de nuevo por el mismo truco.

Espero que ayude.