Uzyskiwanie Pdb w Emacs do używania procesu Python z bieżącego virtualenv

Question

Jestem debugowania niektóre kodu Pythona w emacs przy użyciu pdb i uzyskanie niektórych problemów z importowaniem. Zależności są instalowane w jednym z moich spersonalizowanych środowisk virtualenv.

Pdb uparcie korzysta z/usr/bin/python, a nie procesu Pythona z mojego virtualenv.

używam virtualenv.el wspierać przełączanie środowisk wewnątrz emacs i za pomocą haków postactivate opisanych w

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

to działa dobrze, gdy uruchomiony Mx python-shell

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

to wskazuje do wszystkich moich bibliotek virtualenv wskazujących, że Python-shell jest tym z mojego virtualenv.

Jest to jednak sprzeczne z M-! Który pyton, który daje /usr/bin/python

Czy ktoś wie, w jaki sposób mogę powiedzieć M-x pdb do przyjęcia procesu Pythona z aktualnie aktywnego virtualenv?

Answer 1

python-shell używa zmiennej python-default-interpreter do określenia, który interpreter python ma użyć. Gdy wartość tej zmiennej to cpython, sprawdzane są zmienne python-python-command i w celu określenia interpretera i argumentów do użycia. Te dwie zmienne są manipulowane przez virtualenv.el, aby ustawić bieżące środowisko wirtualne.

Tak więc, korzystając z polecenia python-shell, korzysta on z wirtualnych środowisk bez żadnego problemu.

Ale jeśli wykonasz M-!python, nie używasz zmiennych python-python-command i python-python-command-args. Więc używa narzędzi Pythona, które znajdzie na twojej ścieżce.

Po wywołaniu M-xpdb używa gud-pdb-command-name jako domyślnego narzędzia pdb. Przedefiniowania tej zmiennej, za każdym razem aktywować środowisko, można zrobić coś takiego:

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

(ad-activate 'virtualenv-activate) 

mieć PDB w środowisku wirtualnym, wykonaj następujące czynności:

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

Następnie edytować pierwszego wiersza z/ścieżka/do/virtual/env/bin/PDB mieć:

#! /usr/bin/env python 

uaktywnianie swoją env i Pdb powinien używać virtualenv Pythona zamiast pytona całego systemu.

Answer 2

Invoke PDB tak:

python -m pdb myscript.py 

Zamiast

pdb myscript.py 

Answer 3

Być może Twój komenda PDB jest przywiązany do pewnej określonej wersji.

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

Następnie spojrzeć na pierwszej linii pdb2.6. Zawiera

#! /usr/bin/python2.6 

Dlatego PDB jest uparty i zawsze wydaje się działać w ramach określonej wersji Pythona. Bo tak naprawdę jest! Właściwie ten rodzaj zależności ma sens w przypadku oprogramowania, takiego jak symboliczny debugger.

Zrobiłem kompilację Pythona2.7 ze źródeł, a pdb nie istnieje, widocznie. Po drobiazgowej analizie znalazłem pdb.py dla Pythona-2.7, w folderze lib. Mam następnie stworzył kilka dowiązania do niego, dla wygody:

$ 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 

Teraz obserwować pierwszą linię pdb2.7. Jest napisane:

#! /usr/bin/env python 

... która wygląda lepiej niż poprzednia wersja. Zasadniczo oznacza to, że pdb zostanie uruchomiony pod bieżącym Pythonem, który zdefiniowałeś w swoim środowisku, cokolwiek to jest, zamiast czegokolwiek na stałe, jak /usr/bin/python lub /usr/bin/python2.6. Dobrze wiedzieć!

Ja również usunięte WPB i pdb2.6 z plików systemowych, raz wolę rozwijać/debug wewnątrz virtualenv. Robiąc to, nie zostanę złapany ponownie przez tę samą sztuczkę.

Mam nadzieję, że to pomaga.