Почему виртуальная библиотека не создает папку DLL?

Question

Мне интересно, в чем причина, почему virtualenv не создает папку DLLs так же, как она создает Lib и Scripts?

Вопрос пришел ко мне, когда у меня возникла следующая проблема с PyDev;
Я установил один из своих virtualenvs как интерпретатор Python, и все было в порядке с одним исключением. Я продолжал получать предупреждения о неразрешенном импорте для всего импорта с модуля select. Это связано с тем, что модуль select, в отличие от большинства других, присутствует только в папке DLL.

Answer 1

Я исследовал эту тему немного больше. Я начал с заявление оператора techtonik - Ответ прост - никто не реализовал его. Это, однако, вызывает другой вопрос - почему никто не реализовал его? Я подозреваю, что ответ потому, что он работает. Это приводит к еще одному вопросу - почему он работает?

Причина все работает без DLLs папки копируется в virtualenv что

• Python ищет sys.path найти любой DLL, необходимую
• sys.path после активации virtualenv содержит путь к исходной DLLs папке

Первое утверждение можно просто протестировать, удалив путь до папки DLLs от sys.path и пытается импортировать модуль select (этот модуль нуждается в select.pyd файлах из папки DLLs), который затем терпит неудачу.

В комментарии, который вы говорите Я хотел бы сохранить библиотеки DLL модуля Python в виртуальной среде вместе с кодом Python. Это возможно путем простого копирования DLLs папки в virtualenv. Причина этого в том, что sys.path после активации virtualenv также содержит путь к папке DLLs внутри virtualenv (хотя при создании virtualenv такой папки не создается). Этот путь помещается до пути к исходной папке DLLs, что означает, что поиск выполняется первым и, таким образом, переопределяет исходную папку DLLs.

Я разместил вопрос под названием DLLs folder on Windows в списке рассылки Python.

Answer 2

ИМО есть больше причин для этого:

• Безопасности: В некоторых средах, политика заключается в отрицании выполнения/загрузке материала от случайных мест, в попытке предотвратить нарушения безопасности. Таким образом,
• Несколько известных DLLloadorder, что предотвращает загрузку вредоносных dll :). Смотрите также here

НТН,

Answer 3

Ответ прост - никто не реализовал его. Когда я создал патч для копирования pythonXX.dll в виртуальную среду - я решал другую проблему:

Когда Python установлен в общесистемном режиме - двоичный файл python.exe, скопированный в virtualenv, всегда может найти свой pythonXX .dll, так как этот .dll доступен из Windows \ System32. Если Python установлен только для текущего пользователя - pythonXX.dll помещается в каталог PythonXX, где находится исходный файл python.exe. Таким образом, проблема, которую я решал, - это исправить virtualenvs, созданный с помощью Python, установленного для текущего пользователя. Это была довольно сложная задача, чтобы выкопать все это.

Назад к вопросу. Я действительно не знаю, как этот pythonXX.dll находит свои DLL-модули - это вопрос для разработчиков Python, но я подозреваю, что он их не находит. Причина, по которой я не исправил эту проблему, а исправление issue #87 заключается в том, что мой код, вероятно, никогда не использовал модули из этого каталога DLL.