python emacs virtualenv pdb

Obteniendo pdb en Emacs para usar el proceso Python del virtualenv actual



(3)

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

Pdb está utilizando tercamente / usr / bin / python y no el proceso de python de mi virtualenv.

Utilizo virtualenv.el para admitir la conmutación de entornos dentro de emacs y a través de los enlaces 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 python-shell

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

Esto apunta a todas mis bibliotecas de virtualenv que indican que el shell de python es el de mi virtualenv.

Esto es contradicho sin embargo por M-! que python, que da / usr / bin / python

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


Invoque pdb así:

python -m pdb myscript.py

En lugar de

pdb myscript.py


Posiblemente, su comando pdb esté vinculado a una determinada versión específica.

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

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

#! /usr/bin/python2.6

Esta es la razón por la que pdb es terco y siempre parece ejecutarse bajo una versión específica de Python. ¡Porque realmente lo es! En realidad, este tipo de dependencia tiene sentido para una pieza de software como un depurador simbólico.

He compilado python2.7 de fuentes y pdb no está allí, al parecer. Después de un escrutinio, encontré pdb.py para python-2.7, debajo de la carpeta lib. Luego he creado algunos enlaces simbólicos a él, 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

Ahora observa 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 ha definido en su entorno, sea lo que sea, en lugar de cualquier código rígido , como / usr / bin / python o /usr/bin/python2.6 . ¡Bueno saber!

También eliminé pdb y pdb2.6 de los archivos del sistema, una vez que prefiero desarrollar / depurar dentro de virtualenv. Haciendo eso, no volveré a ser atrapado por el mismo truco.

Espero que ayude.


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 utilizar. Estas dos variables son manipuladas por virtualenv.el para establecer el entorno virtual actual.

Entonces, cuando usa el comando python-shell , usa sus entornos virtuales sin ningún problema.

Pero, cuando haces M-! python , no estás usando las variables python-python-command y python-python-command-args . Así que usa las herramientas de python que encuentra en tu camino.

Cuando llamas a Mx pdb usa gud-pdb-command-name como la herramienta pdb predeterminada. Para redefinir esta variable, cada vez que active un entorno, 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)

Para tener pdb en su entorno virtual, haga lo siguiente:

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

Luego edite la primera línea de / path / to / virtual / env / bin / pdb para que tenga:

#! /usr/bin/env python

Reactivar su env y Pdb ahora debería usar su python virtualenv en lugar del python de todo el sistema.