2011-07-11 31 views
8

Tôi tự hỏi lý do virtualenv không tạo ra thư mục DLLs giống như cách nó tạo ra LibScripts?Tại sao virtualenv không tạo thư mục DLL?

Câu hỏi đặt ra cho tôi khi tôi gặp vấn đề sau với PyDev;
Tôi đặt một trong các virtualenv của mình làm thông dịch viên Python và mọi thứ đều ổn với một ngoại lệ. Tôi đã tiếp tục nhận được cảnh báo về việc nhập khẩu chưa được giải quyết cho tất cả các mục nhập từ mô-đun select. Điều này là do mô-đun select, không giống như hầu hết những người khác, chỉ xuất hiện trong thư mục DLL.

Trả lời

8

Tôi đã nghiên cứu chủ đề này thêm một chút. Tôi bắt đầu từ số tuyên bố của techtonik - Câu trả lời rất đơn giản - không ai triển khai nó. Điều này tuy nhiên, đặt ra một câu hỏi khác - tại sao không ai thực hiện nó? Tôi nghi ngờ câu trả lời là bởi vì nó hoạt động. Điều này dẫn đến một câu hỏi khác - tại sao nó hoạt động?

Lý do mọi thứ hoạt động mà không cần DLLs thư mục được sao chép vào virtualenv là

  • Python tìm kiếm sys.path tìm thấy bất kỳ dll nó cần
  • sys.path sau khi kích hoạt virtualenv chứa đường dẫn đến bản gốc DLLs thư mục

Câu lệnh đầu tiên có thể được kiểm tra đơn giản bằng cách xóa đường dẫn đến DLLs thư mục từ sys.path và cố nhập mô-đun select (mô-đun này cần select.pyd tệp từ thư mục DLLs) mà sau đó không thành công.

Trong nhận xét bạn nói Tôi muốn giữ các tệp DLL của mô-đun Python trong môi trường ảo cùng với mã Python. Có thể bằng cách sao chép DLLs thư mục vào virtualenv. Lý do hoạt động này là sys.path sau khi kích hoạt virtualenv cũng chứa đường dẫn đến thư mục DLLs bên trong virtualenv (mặc dù không có thư mục nào được tạo khi tạo virtualenv). Đường dẫn này được đặt trước đường dẫn đến thư mục DLLs gốc có nghĩa là nó được tìm kiếm trước tiên và do đó ghi đè thư mục DLLs gốc.

Tôi đã đăng câu hỏi có tiêu đề DLLs folder on Windows tại danh sách gửi thư của Python.

+0

"sys.path sau khi kích hoạt virtualenv chứa đường dẫn đến thư mục DLL gốc" Tôi không 'kích hoạt' env của mình, và nó cũng chứa đường dẫn đến thư mục DLL gốc trong 'sys.path'. Tôi có hiểu lầm bạn không? – cubuspl42

+1

* (...) 'sys.path' sau khi kích hoạt của virtualenv chứa ** cũng ** đường dẫn đến thư mục' DLLs' bên trong virtualenv (...) * Nếu không có virtualenv được kích hoạt 'sys.path' chứa đường dẫn đến * DLLs * thư mục từ cài đặt của Python. Sau khi virtualenv được kích hoạt 'sys.path' chứa ** cả ** đường dẫn - đến thư mục * DLLs * của virtualenv và cũng vào thư mục * DLLs * từ cài đặt của Python. –

3

IMO có nhiều lý do cho điều đó:

  • An ninh: Trong một số môi trường, chính sách này là để từ chối thực hiện/tải công cụ từ địa điểm ngẫu nhiên, trong một nỗ lực để ngăn chặn vi phạm an ninh. Do đó,
  • Phần nổi tiếng DLLloadorder, ngăn các tệp tin độc hại được tải :). Xem thêm here

HTH,

+0

Câu hỏi đặt ra là Windows không có chính sách nào có thể ngăn chặn tải dll từ bất kỳ vị trí cụ thể nào. –

+0

Ngay cả khi không có chính sách rõ ràng tại chỗ, thứ tự tải DLL vẫn hợp lệ (và bạn cần phải thêm nó vào danh sách). Ngoài ra, với vô số tùy chọn, virtualenv sẽ cần phải đối phó với nhiều biến thể, điều này có thể không khả thi. –

+0

Thứ tự tải DLL không liên quan ở đây vì tôi đã viết trong câu trả lời của tôi Python tìm kiếm các dll trong các thư mục được đặt trong 'sys.path'. –

6

Câu trả lời rất đơn giản - không ai thực hiện nó. Khi tôi tạo bản vá để sao chép pythonXX.dll vào môi trường virtualenv - Tôi đã giải quyết một vấn đề khác:

Khi Python được cài đặt trên toàn hệ thống - nhị phân python.exe được sao chép vào virtualenv luôn có thể tìm thấy pythonXX của nó .dll, bởi vì dll này có sẵn từ Windows \ System32. Nếu Python được cài đặt chỉ cho người dùng hiện tại - pythonXX.dll được đặt vào thư mục PythonXX nơi python.exe gốc nằm. Vì vậy, vấn đề tôi đã giải quyết là sửa chữa virtualenvs được tạo bằng Python được cài đặt cho người dùng hiện tại. Thật là một vấn đề khi đào bới tất cả những thứ này.

Quay lại câu hỏi. Tôi không thực sự biết làm thế nào pythonXX.dll này tìm thấy mô-đun DLLs của nó - đây là một câu hỏi cho các nhà phát triển Python, nhưng tôi nghi ngờ rằng nó không tìm thấy chúng. Lý do tại sao tôi đã không khắc phục vấn đề này trong khi sửa chữa issue #87 là mã của tôi có lẽ không bao giờ được sử dụng các mô-đun từ thư mục DLL này.

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