Подтвердить что ты не робот

Получение pdb в Emacs для использования процесса Python из текущего virtualenv

Я отлаживаю некоторый код python в emacs с помощью pdb и получаю некоторые проблемы с импортом. Зависимости устанавливаются в одной из моих виртуальных виртуальных сред.

Pdb упрямо использует /usr/bin/python, а не процесс python из моего virtualenv.

Я использую virtualenv.el для поддержки переключения сред в emacs и с помощью переключателей postactivate, описанных в

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

Это хорошо работает при запуске M-x python-shell

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

Это указывает на все мои виртуальные библиотеки, указывающие, что оболочка python - это моя виртуальная программа.

Это противоречит, однако, M-! который python, который дает /usr/bin/python

Кто-нибудь знает, как я могу сказать M-x pdb, чтобы принять процесс python из активного виртуального виртуального?

4b9b3361

Ответ 1

python-shell использует переменную python-default-interpreter, чтобы определить, какой интерпретатор python использовать. Когда значение этой переменной cpython, для определения интерпретатора используются переменные python-python-command и python-python-command-args и аргументы для использования. Эти две переменные управляются с помощью virtualenv.el, чтобы установить текущую виртуальную среду.

Поэтому, когда вы используете команду python-shell, она без проблем использует ваши виртуальные среды.

Но, когда вы делаете M-! python, вы не используете переменные python-python-command и python-python-command-args. Поэтому он использует инструменты python, которые он находит на вашем пути.

Когда вы вызываете M-x pdb, он использует gud-pdb-command-name как инструмент pdb по умолчанию. Чтобы переопределить эту переменную, каждый раз, когда вы активируете среду, вы можете сделать что-то вроде этого:

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

(ad-activate 'virtualenv-activate)

Чтобы иметь pdb в вашей виртуальной среде, выполните следующие действия:

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

Затем отредактируйте первую строку /path/to/virtual/env/bin/pdb, чтобы:

#! /usr/bin/env python

Повторно активируйте ваш env, и Pdb теперь должен использовать ваш virtualenv python вместо общесистемного питона.

Ответ 2

Вызвать pdb следующим образом:

python -m pdb myscript.py

Вместо

pdb myscript.py

Ответ 3

Возможно, ваша команда pdb привязана к определенной определенной версии.

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

Затем посмотрите на первую строку pdb2.6. Он содержит

#! /usr/bin/python2.6

Вот почему pdb упрям ​​и всегда работает под определенной версией Python. Потому что это действительно так! На самом деле, такая зависимость имеет смысл для части программного обеспечения, такого как символический отладчик.

Я скомпилировал python2.7 из источников, и pdb не существует, по-видимому. После некоторого изучения я нашел pdb.py для python-2.7 под папкой lib. Затем я создал некоторые символические ссылки для удобства:

$ 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

Теперь обратите внимание на первую строку pdb2.7. Он гласит:

#! /usr/bin/env python

... который выглядит лучше, чем предыдущая версия. Это в основном означает, что pdb будет запущен под текущим Python, который вы определили в своей среде, независимо от того, что он есть, вместо чего-либо жестко закодированного, например, /usr/bin/python или/usr/bin/python2.6. Полезно знать!

Я также удалил pdb и pdb2.6 из системных файлов, как только я предпочитаю разрабатывать/отлаживать внутри virtualenv. Сделав это, я не буду снова поймать тот же трюк.

Надеюсь, это поможет.