Why doesn't virtualenv create DLLs folder?

Question

I'm wondering what's the reason virtualenv doesn't create DLLs folder the same way it creates Lib and Scripts ones?

The question came to me when I had the following problem with PyDev;
I set one of my virtualenvs as a Python interpreter and everything was ok with one exception. I've kept getting warnings about unresolved import for all imports from select module. This is because select module, unlike most others, is present only in the DLLs folder.

Answer 1

I investigated this subject a little more. I started from techtonik's statement - The answer is simple - nobody implemented it. This however, begs another question - why nobody implemented it? I suspect the answer is because it works. This leads to yet another question - why does it work?

The reason everything works without DLLs folder being copied into virtualenv is that

• Python searches sys.path to find any dll it needs
• sys.path after virtualenv's activation contains path to the original DLLs folder

The first statement can be simply tested by removing path to DLLs folder from sys.path and trying to import select module (this module needs select.pyd file from DLLs folder) which then fails.

In the comment you say I'd like to keep Python module's DLLs in the virtual environment along with the Python code. That's possible by simply copying DLLs folder into virtualenv. The reason this works is that sys.path after virtualenv's activation contains also path to the DLLs folder inside virtualenv (although there's no such folder being created when creating virtualenv). This path is placed before path to the original DLLs folder which means it's being searched first and thus overrides the original DLLs folder.

I posted question titled DLLs folder on Windows at Python's mailing list.

Answer 2

The answer is simple - nobody implemented it. When I created the patch to copy pythonXX.dll into virtualenv environment - I was solving a different problem:

When Python is installed system-wide - the python.exe binary that is copied to virtualenv is always able to find its pythonXX.dll, because this .dll is available from Windows\System32. If Python is installed only for current user - the pythonXX.dll is placed into PythonXX dir where original python.exe is located. So the problem I was solving is to fix virtualenvs created with Python installed for current user. It was quite a problem to dig up all this stuff.

Back to the question. I don't really know how this pythonXX.dll finds its DLLs modules - this is a question to Python developers, but I suspect that it doesn't find them. The reason why I didn't fix this issue while fixing issue #87 is that my code probably never used modules from this DLLs directory.

Answer 3

IMO there are more reasons for that:

• Security: In some environments, the policy is to deny executing/loading stuff from random locations, in an attempt to prevent security breaches. Thus,
• The somewhat famous DLL load order, which prevents malicious dlls to be loaded :). See also here

HTH,