从另一个 Python 安装导入的模块 [英] Module being imported from another Python install

问题描述

我正在 Windows Server 2012 上运行多个 Python 安装.我可能可以找到解决此问题的方法，但我很好奇发生了什么.我很担心从根本上改变安装，以防我破坏了我可能不知道的其他人的 Python 计划任务.

I'm running multiple installs of Python on Windows Server 2012. I can probably find a way to work around this, but I'm curious as to what is going on. I'm wary about radically changing the installs in case I break other people's Python scheduled tasks that I may not be aware of.

(以下所有代码框都是 PowerShell).

(All the code boxes below are PowerShell).

PS C:\> C:\Python34\Scripts\pip.exe list
jdcal (1.0)
pip (7.1.2)
setuptools (12.0.5)
virtualenv (13.1.2)

虽然这个 Python 3.4 安装没有安装 Django，但它似乎从 Python 33x86 安装中选择了版本.正常吗?

Although this Python 3.4 install doesn't have Django installed, it appears to pick up the version from the Python 33x86 install. Is that normal?

PS C:\> C:\Python34\python.exe -c "import django; print(django.get_version())"
1.6.5
PS C:\> C:\Python33x86\python.exe -c "import django; print(django.get_version())"
1.6.5

我已经创建了一个基于 Python 3.4 的 Python virtualenv 并在其中安装了 Django 1.8.4.做一个pip list"确认它安装正确:-

I've created a Python virtualenv based on Python 3.4 and installed Django 1.8.4 in it. Doing a "pip list" confirms that it is installed correctly:-

PS C:\> D:\PyVirtualEnvs\example_py34\Scripts\activate.bat
PS C:\> D:\PyVirtualEnvs\example_py34\Scripts\pip.exe list | Select-String "Django "
Django (1.8.4)

但是，当我在那个 virtualenv 中导入时，我得到了 Django 版本 1.6.5:-

However, when I import within that virtualenv, I get Django version 1.6.5:-

PS C:\> D:\PyVirtualEnvs\example_py34\Scripts\python.exe -c "import django; print(django.get_version())"
1.6.5

这是 virtualenv 中的错误还是我遗漏了什么?

Is this a bug in virtualenv or am I missing something?

它是否与这个问题有关?

使用 pyvenv 时会发生同样的事情，如建议的那样火腿三明治.

The same thing happens when using pyvenv, as suggested by ham-sandwich.

推荐答案

我已经发现了这种行为的原因.PYTHONPATH 环境变量被设置为机器上异常位置的 Python 安装.

I've discovered the reason for this behaviour. The PYTHONPATH environment variable was set to a Python installation at an unusual location on the machine.

根据文档，PYTHONPATH用作当前目录中未找到模块时的导入位置.

According to the documentation, PYTHONPATH is used as the import location when the module is not found in the current directory.

当导入名为 spam 的模块时，解释器首先搜索具有该名称的内置模块.如果未找到，它将在变量 sys.path 给出的目录列表中搜索名为 spam.py 的文件.sys.path 从以下位置初始化:

When a module named spam is imported, the interpreter first searches for a built-in module with that name. If not found, it then searches for a file named spam.py in a list of directories given by the variable sys.path. sys.path is initialized from these locations:

• 包含输入脚本的目录(或当前目录).
• PYTHONPATH(目录名称列表，语法与 shell 变量 PATH 相同).
• 依赖于安装的默认值.

出于某种原因，激活/停用脚本没有设置/取消设置 PYTHONPATH.它确实设置了 PYTHONHOME，但这似乎不会影响导入.这感觉像是 virtualenv 和 pyvenv 中的一个错误(我都试过).

For some reason PYTHONPATH is not set/unset by the activate/deactivate scripts. It does set PYTHONHOME, but this doesn't seem to affect imports. This feels like a bug in virtualenv and pyvenv (I tried both).

原始的 activate.bat 脚本改变了一个set"变量，它不会影响 $env:PYTHONPATH.Activate.ps1 尝试将原始 PYTHONPATH 保存在变量中，将其设置为虚拟环境目录，然后在停用时恢复原始 PYTHONPATH.这些都不再起作用，可能是由于 Powershell 或 Python 更新.

The original activate.bat scripts change a "set" variable, which doesn't affect the $env:PYTHONPATH. Activate.ps1 attempts to save the original PYTHONPATH in a variable, set it to the virtual environment directory, then on deactivate, restore the original PYTHONPATH. Neither of these work anymore, possibly due to a Powershell or Python update.

我们的解决方案是修改激活和停用脚本(PoSh 或 bat)以在两个硬编码值之间切换 PYTHONPATH.

The solution for us is to modify the activate and deactivate scripts (PoSh or bat) to switch the PYTHONPATH between two hard-coded values.

这篇关于从另一个 Python 安装导入的模块的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！