为什么 virtualenv 不创建 DLLs 文件夹？
我想知道 virtualenv 没有像创建 Lib 和 Scripts 文件夹一样创建 DLLs 文件夹的原因是什么？
当我在使用 PyDev 时遇到以下问题时，我就想到了这个问题；
我将我的一个 virtualenv 设置为 Python 解释器，除了一个例外，一切正常。对于来自 select 模块的所有导入，我不断收到有关未解决的导入的警告。这是因为 select 模块与大多数其他模块不同，仅存在于 DLL 文件夹中。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我对这个主题进行了更多研究。我从techtonik的声明开始 - 答案很简单 - 没有人实现它。然而，这又引出了另一个问题 - 为什么没有人实现它？我怀疑答案是因为它有效。这又引出了另一个问题——它为什么有效？
无需将
DLLs文件夹复制到 virtualenv 即可一切正常的原因是，sys.path以查找它需要sys.path的任何 dllDLLs文件夹的路径第一条语句可以通过从
sys.path中删除DLLs文件夹的路径并尝试导入来简单测试select模块（该模块需要DLLs文件夹中的select.pyd文件），然后失败。在评论中，您说我想将 Python 模块的 DLL 与 Python 代码一起保留在虚拟环境中。只需将
DLLs文件夹复制到 virtualenv 即可实现这一点。这样做的原因是 virtualenv 激活后的 sys.path 还包含 virtualenv 内的 DLLs 文件夹的路径（尽管创建 virtualenv 时没有创建这样的文件夹）。该路径放置在原始DLLs文件夹的路径之前，这意味着首先搜索它，从而覆盖原始DLLs文件夹。我在 Python 的邮件列表中发布了标题为 Windows 上的 DLLs 文件夹 的问题。
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
DLLsfolder being copied into virtualenv is thatsys.pathto find any dll it needssys.pathafter virtualenv's activation contains path to the originalDLLsfolderThe first statement can be simply tested by removing path to
DLLsfolder fromsys.pathand trying to importselectmodule (this module needsselect.pydfile fromDLLsfolder) 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
DLLsfolder into virtualenv. The reason this works is thatsys.pathafter virtualenv's activation contains also path to theDLLsfolder inside virtualenv (although there's no such folder being created when creating virtualenv). This path is placed before path to the originalDLLsfolder which means it's being searched first and thus overrides the originalDLLsfolder.I posted question titled DLLs folder on Windows at Python's mailing list.
答案很简单——没有人实施它。当我创建补丁将 pythonXX.dll 复制到 virtualenv 环境中时 - 我正在解决一个不同的问题：
当系统范围内安装 Python 时 - 复制到 virtualenv 的 python.exe 二进制文件始终能够找到其 pythonXX.dll，因为此 .dll 可从 Windows\System32 获取。如果仅为当前用户安装 Python - pythonXX.dll 将被放置到原始 python.exe 所在的 PythonXX 目录中。所以我要解决的问题是修复为当前用户安装的Python创建的virtualenvs。把这些东西挖出来是一个很大的问题。
回到问题。我真的不知道这个 pythonXX.dll 如何找到它的 DLL 模块 - 这是 Python 开发人员的问题，但我怀疑它找不到它们。我在修复 issue #87 时没有解决此问题的原因是我的代码可能从未使用过此 DLL 目录中的模块。
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.
IMO 还有更多原因：
HTH，
IMO there are more reasons for that:
HTH,