Pourquoi virtualenv ne crée-t-il pas de dossier DLL?

Question

Je me demande quelle est la raison pour laquelle virtualenv ne crée pas le dossier DLLs de la même manière qu'il crée Lib et Scripts?

La question m'est venue quand j'ai eu le problème suivant avec PyDev;
J'ai défini un de mes virtualenvs comme un interpréteur Python et tout était correct avec une exception. J'ai continué à recevoir des avertissements sur l'importation non résolue pour toutes les importations du module select. C'est parce que le module select, contrairement à la plupart des autres, est présent uniquement dans le dossier DLL.

Answer 1

J'ai étudié ce sujet un peu plus. Je suis parti de La déclaration de techtonik - La réponse est simple - personne ne l'a implémenté. Ceci cependant, soulève une autre question - pourquoi personne ne l'a implémenté? Je soupçonne que la réponse est parce que cela fonctionne. Cela conduit à une autre question: pourquoi cela fonctionne-t-il?

Le tout raison fonctionne sans DLLs dossier copié dans virtualenv est que

• Python recherche sys.path pour trouver une dll dont il a besoin
• sys.path après l'activation de virtualenv contient chemin du dossier DLLs d'origine

La première instruction peut être simplement testée en supprimant le chemin d'accès au dossier DLLs de sys.path et en essayant d'importer le module select (ce module a besoin du fichier select.pyd du dossier DLLs) qui échoue alors.

Dans le commentaire, vous dites Je voudrais garder les DLL du module Python dans l'environnement virtuel avec le code Python. C'est possible en copiant simplement le dossier DLLs dans virtualenv. La raison pour laquelle cela fonctionne est que sys.path après l'activation de virtualenv contient également le chemin d'accès au dossier DLLs dans virtualenv (bien qu'aucun dossier de ce type ne soit créé lors de la création de virtualenv). Ce chemin est placé avant le chemin d'accès au dossier DLLs d'origine, ce qui signifie qu'il est recherché en premier et remplace donc le dossier original DLLs.

J'ai posté une question intitulée DLLs folder on Windows à la liste de diffusion de Python.

Answer 2

OMI il y a plus de raisons pour cela:

• Sécurité: Dans certains environnements, la politique est de refuser l'exécution/stuff de chargement à partir d'emplacements aléatoires, pour tenter de prévenir les atteintes à la sécurité. Ainsi,
• Le peu célèbre DLLloadorder, qui empêche le chargement de DLL malveillantes :). Voir aussi here

HTH,

Answer 3

La réponse est simple - personne a mise en œuvre. Lorsque j'ai créé le correctif pour copier pythonXX.dll dans l'environnement virtualenv - je résolvais un problème différent:

Lorsque Python est installé sur le système - le binaire python.exe copié dans virtualenv est toujours capable de trouver son pythonXX .dll, car ce fichier .dll est disponible à partir de Windows \ System32. Si Python est installé uniquement pour l'utilisateur actuel, le fichier pythonXX.dll est placé dans le répertoire PythonXX où se trouve l'original python.exe. Donc, le problème que je résolvais est de réparer virtualenvs créé avec Python installé pour l'utilisateur actuel. C'était assez difficile de déterrer tout ça.

Retour à la question. Je ne sais pas vraiment comment ce pythonXX.dll trouve ses modules DLL - c'est une question pour les développeurs Python, mais je soupçonne qu'il ne les trouve pas. La raison pour laquelle je n'ai pas résolu ce problème en corrigeant issue #87 est que mon code n'a probablement jamais utilisé de modules de ce répertoire DLL.