【发布时间】:2020-09-09 11:55:39
【问题描述】:
当通过python -m venv .venv 创建虚拟环境然后激活该环境时,我注意到在Windows 上,环境的根目录是sys.path 报告的导入路径的一部分,但对于Linux 则不是。
Python 版本:3.8.2
例子:
python -m venv .venv
在 Windows 上:
>>> import sys
>>> sys.path
['', 'c:\\temp\\.venv\\Scripts\\python36.zip', 'C:\\Python36\\DLLs', 'C:\\Python36\\lib', 'C:\\Python36', 'c:\\temp\\.venv', 'c:\\temp\\.venv\\lib\\site-packages']
>>> sys.prefix
'c:\\temp\\.venv'
注意路径中的条目c:\\temp\\.venv。
在 Linux 上:
>>> import sys
>>> sys.path
['', '/usr/local/lib/python38.zip', '/usr/local/lib/python3.8', '/usr/local/lib/python3.8/lib-dynload', '/carsten/.venv/lib/python3.8/site-packages']
>>> sys.prefix
'/carsten/.venv'
请注意,环境的根不是路径的一部分。
这是设计上的差异还是一个错误?
【问题讨论】:
-
@ErykSun,我查看了
C:\temp\.venv内部,但没有找到C:\temp\.venv是如何进入 sys.path 的。 -
@ErykSun,没有。例如,我查看了
activate.bat,但没有找到将C:\temp\.venv放入sys.path 的任何内容。不知道我表达清楚了吗 -
@Philippe,这是导入站点模块的正常解释器启动顺序。使用
-S运行以跳过导入site.py,您将不再在列表中看到venv 前缀目录。在当前的 site.py 中,addsitepackages调用getsitepackages,如果路径分隔符是反斜杠(考虑到更好的可用方法,这是一种奇怪的识别 Windows 的方法),它首先添加prefix,然后添加os.path.join(prefix, libdir, "site-packages")。 -
谢谢你的解释,虽然我还是不明白。我想我需要通过您的 cmets(带有不同的链接)才能完全理解。
-
@ErykSun 非常感谢您的解释和对差异起源的解释。所以基本上就是这条线github.com/python/cpython/blob/master/Lib/site.py#L348
标签: python linux windows python-venv