¿Por qué Virtualenv no crea una carpeta DLL?

Question

Me pregunto cuál es la razón por la cual virtualenv no crea la carpeta DLLs de la misma manera que crea Lib y Scripts?

La pregunta vino a mí cuando tuve el siguiente problema con PyDev;
Configuré uno de mis virtualenvs como un intérprete de Python y todo estaba bien con una excepción. He seguido recibiendo advertencias sobre la importación no resuelta para todas las importaciones desde el módulo select. Esto se debe a que el módulo select, a diferencia de la mayoría de los demás, está presente solo en la carpeta DLL.

Answer 1

He investigado este tema un poco más. Empecé desde declaración de techtonik - La respuesta es simple: nadie lo implementó. Esto, sin embargo, plantea otra pregunta: ¿por qué nadie lo implementó? Sospecho que la respuesta es porque funciona. Esto lleva a otra pregunta: ¿por qué funciona?

La razón por la que todo funciona sin DLLs carpeta que se copiará en virtualenv es que

• Python busca sys.path de encontrar cualquier archivo DLL que necesita
• sys.path después de la activación de virtualenv contiene ruta de acceso al DLLs carpeta original

La primera declaración se puede probar simplemente eliminando la ruta a la carpeta DLLs desde sys.path y tratando de importar el módulo select (este módulo necesita el archivo select.pyd de la carpeta DLLs) que luego falla.

En el comentario dices Me gustaría mantener las DLL del módulo de Python en el entorno virtual junto con el código de Python. Eso es posible simplemente copiando la carpeta DLLs en virtualenv. La razón por la que esto funciona es que sys.path después de la activación de virtualenv también contiene la ruta a la carpeta DLLs dentro de virtualenv (aunque no se crea dicha carpeta al crear virtualenv). Esta ruta se coloca antes de la ruta a la carpeta original DLLs, lo que significa que se está buscando primero y, por lo tanto, reemplaza la carpeta original DLLs.

He publicado la pregunta titulada DLLs folder on Windows en la lista de correo de Python.

Answer 2

OMI hay más razones para ello:

• de seguridad: En algunos entornos, la política es negar la ejecución/material de carga de lugares al azar, en un intento de prevenir las violaciones de seguridad. Por lo tanto,
• El algo famoso DLLloadorder, que impide que se carguen dlls maliciosos :). Ver también here

HTH,

Answer 3

La respuesta es simple - nadie lo implementó. Cuando creé el parche para copiar pythonXX.dll en el entorno virtualenv - resolvía un problema diferente:

Cuando Python está instalado en todo el sistema, el binario python.exe que se copia a virtualenv siempre puede encontrar su pythonXX .dll, porque este .dll está disponible desde Windows \ System32. Si Python está instalado solo para el usuario actual, pythonXX.dll se coloca en el directorio PythonXX donde se encuentra el python.exe original. Entonces, el problema que estaba resolviendo es arreglar virtualenvs creados con Python instalado para el usuario actual. Fue todo un problema desenterrar todo esto.

Volver a la pregunta. Realmente no sé cómo este pythonXX.dll encuentra sus módulos DLL: esta es una pregunta para los desarrolladores de Python, pero sospecho que no los encuentra. La razón por la que no solucioné este problema al reparar issue #87 es que mi código probablemente nunca usó módulos de este directorio de DLL.