Получение 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 из активного виртуального виртуального?
Ответы
Ответ 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. Сделав это, я не буду снова поймать тот же трюк.
Надеюсь, это поможет.