Perché virtualenv non crea la cartella DLL?

Question

Mi chiedo quale sia la ragione per cui virtualenv non crea la cartella DLLs nello stesso modo in cui crea Lib e Scripts?

La domanda mi è venuta quando ho avuto il seguente problema con PyDev;
Ho impostato uno dei miei virtualenv come interprete Python e tutto è andato bene con un'eccezione. Ho continuato a ricevere avvisi sull'importazione non risolta per tutte le importazioni dal modulo select. Questo perché il modulo select, a differenza della maggior parte degli altri, è presente solo nella cartella DLL.

Answer 1

Ho studiato un po 'di più questo argomento. Ho iniziato da dichiarazione di techtonik - La risposta è semplice: nessuno l'ha implementata. Questo, tuttavia, fa sorgere un'altra domanda: perché nessuno l'ha implementata? Sospetto che la risposta sia perché funziona. Questo porta a un'altra domanda: perché funziona?

Il motivo tutto funziona senza cartella DLLs essere copiato in virtualenv è che

• Python cerca sys.path di trovare qualsiasi dll di cui ha bisogno
• sys.path dopo l'attivazione di virtualenv contiene percorso alla DLLs cartella originale

La prima istruzione può essere semplicemente testata rimuovendo il percorso della cartella DLLs da sys.path e prova ad importare il modulo select (questo modulo ha bisogno del file select.pyd dalla cartella DLLs) che poi fallisce.

Nel commento dici Mi piacerebbe mantenere le DLL del modulo Python nell'ambiente virtuale insieme al codice Python. Ciò è possibile semplicemente copiando la cartella DLLs in virtualenv. Il motivo per cui questo funziona è che sys.path dopo l'attivazione di virtualenv contiene anche il percorso della cartella DLLs all'interno di virtualenv (sebbene non sia stata creata tale cartella durante la creazione di virtualenv). Questo percorso viene posizionato prima del percorso della cartella originale DLLs, il che significa che viene ricercata per prima e quindi sostituisce la cartella originale DLLs.

Ho postato la domanda dal titolo DLLs folder on Windows alla mailing list di Python.

Answer 2

IMO ci sono più motivi per questo:

• Sicurezza: In alcuni ambienti, la politica è di negare l'esecuzione di roba/caricamento da posizioni casuali, nel tentativo di prevenire violazioni della sicurezza. Quindi,
• Il famoso numero DLLorder, che impedisce il caricamento di dll dannose :). Vedere anche here

HTH,

Answer 3

La risposta è semplice - nessuno implementato. Quando ho creato la patch per copiare pythonXX.dll in ambiente virtualenv: stavo risolvendo un altro problema:

Quando Python è installato a livello di sistema - il file python.exe che viene copiato su virtualenv è sempre in grado di trovare il suo pythonXX .dll, perché questo .dll è disponibile da Windows \ System32. Se Python è installato solo per l'utente corrente, pythonXX.dll viene posto nella directory PythonXX dove si trova python.exe originale. Quindi il problema che stavo risolvendo è quello di correggere i virtualenv creati con Python installato per l'utente corrente. È stato un bel problema scavare tutta questa roba.

Torna alla domanda. Non so davvero come questo pythonXX.dll trovi i suoi moduli DLL - questa è una domanda per gli sviluppatori Python, ma ho il sospetto che non li trovi. Il motivo per cui non ho risolto il problema durante il fixing di issue #87 è che probabilmente il mio codice non ha mai utilizzato i moduli da questa directory DLL.