2010-09-17 19 views
20

Tôi đang gỡ lỗi một số mã python trong các emacs bằng pdb và nhận một số vấn đề nhập. Các phụ thuộc được cài đặt trong một trong các môi trường ảo hóa riêng biệt của tôi.Nhận pdb trong Emacs để sử dụng quy trình Python từ virtualenv

Pdb là cứng đầu sử dụng/usr/bin/python và không phải là quá trình python từ virtualenv của tôi.

tôi sử dụng virtualenv.el để hỗ trợ chuyển đổi của môi trường bên trong emacs và thông qua các móc postactivate được mô tả trong

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

này hoạt động tốt khi chạy Mx python-vỏ

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

điểm này cho tất cả các thư viện virtualenv của tôi chỉ ra rằng python-shell là của virtualenv của tôi.

Điều này mâu thuẫn với M-! mà python, cung cấp cho /usr/bin/python

Có ai biết cách tôi có thể yêu cầu M-x pdb áp dụng quy trình python từ virtualenv hiện đang hoạt động không?

+1

Bài đăng của bạn đề cập đến [gói virtualenv cũ của tôi] (https://github.com/aculich/virtualenv.el) mà tôi không còn duy trì; có ít nhất 3 gói mới, chủ động được duy trì: [virtualenvwrapper] (https://github.com/porterjamesj/virtualenvwrapper.el), [pyvenv] (https://github.com/jorgenschaefer/pyvenv), [python- môi trường] (https://github.com/tkf/emacs-python-environment) – aculich

+0

Cập nhật hữu ích - cảm ơn @aculich – codeasone

Trả lời

8

python-shell sử dụng biến python-default-interpreter để xác định trình thông dịch trăn nào sẽ sử dụng. Khi giá trị của biến này là cpython, các biến số python-python-commandpython-python-command-args được tham khảo để xác định thông dịch viên và các đối số để sử dụng. Hai biến này được điều khiển bởi virtualenv.el để đặt môi trường ảo hiện tại.

Vì vậy, khi bạn sử dụng lệnh python-shell, nó sử dụng môi trường ảo của bạn mà không gặp bất kỳ sự cố nào.

Nhưng, khi bạn làm M-!python, bạn không sử dụng các biến python-python-commandpython-python-command-args. Vì vậy, nó sử dụng các công cụ python nó tìm thấy trong đường dẫn của bạn.

Khi bạn gọi M-xpdb, sử dụng gud-pdb-command-name làm công cụ mặc định pdb. Để xác định lại biến này, mỗi khi bạn kích hoạt một môi trường, bạn có thể làm một cái gì đó như thế này:

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

(ad-activate 'virtualenv-activate) 

Để có pdb trong môi trường ảo của bạn, hãy thực hiện như sau:

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

Sau đó chỉnh sửa dòng đầu tiên của/path/to/virtual/env/bin/pdb phải có:

#! /usr/bin/env python 

Kích hoạt env của bạn và bây giờ PDB nên sử dụng python virtualenv của bạn thay vì trăn toàn hệ thống.

+0

Cảm ơn Jerome. Đối với những người khác cố gắng để có được lưu ý làm việc này mà tôi đã phải cp/usr/bin/pdb để /bin và thay đổi shebang để sử dụng virtualenv python executable. Điều này là do mkvirtualenv --no-site-packages không gửi pdb cần thiết vào thư mục/bin của môi trường mới được tạo ra. – codeasone

+0

Thx để biết chi tiết. Bạn cũng có thể tạo liên kết tượng trưng để tránh sao chép các tệp. –

10

Gọi pdb như thế này:

python -m pdb myscript.py 

Thay vì

pdb myscript.py 
1

Có thể, pdb lệnh của bạn được gắn với một phiên bản cụ thể nào đó.

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

Sau đó, hãy xem dòng đầu tiên của pdb2.6. Nó chứa

#! /usr/bin/python2.6 

Đây là lý do tại sao pdb là bướng bỉnh và luôn luôn có vẻ để chạy theo một phiên bản cụ thể của Python. Bởi vì nó thực sự là! Trên thực tế, loại phụ thuộc này có ý nghĩa đối với một phần mềm giống như trình gỡ lỗi tượng trưng.

Tôi đã biên soạn python2.7 từ các nguồn và pdb không có ở đó, rõ ràng. Sau khi xem xét kỹ lưỡng, tôi tìm thấy pdb.py cho python-2.7, trong thư mục lib. Sau đó tôi đã tạo một số liên kết tượng trưng cho nó, để thuận tiện:

$ 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 

Bây giờ hãy quan sát dòng đầu tiên của pdb2.7. Nó đọc:

#! /usr/bin/env python 

... trông đẹp hơn phiên bản trước. Về cơ bản nó có nghĩa là pdb sẽ được khởi chạy dưới Python hiện tại bạn đã xác định trong môi trường của bạn, bất kể nó là gì, thay vì bất cứ thứ gì được mã hóa cứng, như /usr/bin/python hoặc /usr/bin/python2.6. Tốt để biết!

Tôi cũng đã xóa pdbpdb2.6 từ tệp hệ thống, khi tôi muốn phát triển/gỡ lỗi bên trong virtualenv. Làm như vậy, tôi sẽ không bị bắt lại bởi cùng một thủ thuật.

Tôi hy vọng điều đó sẽ hữu ích.

Các vấn đề liên quan