一觉醒来，发现原本在虚拟环境里使用python xxx.py，所有原本安装好的包都无法调用了。于是开始debug：
- 进入配置好的虚拟环境env_name，检查一下sys.path中保存的库的路径：
$ source activate env_name
$ python -m site
输出结果为：
sys.path = [
'/my_model/',
'/root/miniconda3/lib/python37.zip',
'/root/miniconda3/lib/python3.7',
'/root/miniconda3/lib/python3.7/lib-dynload',
'/root/miniconda3/lib/python3.7/site-packages',
]
USER_BASE: '/root/.local' (exists)
USER_SITE: '/root/.local/lib/python3.7/site-packages' (doesn't exist)
ENABLE_USER_SITE: True
检查一下site.py的位置：
$ python -m site -help
输出结果为：
/root/miniconda3/lib/python3.7/site.py [--user-base] [--user-site]
Without arguments print some useful information
With arguments print the value of USER_BASE and/or USER_SITE separated
by ':'.
Exit codes with --user-base or --user-site:
0 - user site directory is enabled
1 - user site directory is disabled by user
2 - uses site directory is disabled by super user
or for security reasons
>2 - unknown error
可见此时所用的python库并不是env_name中对应版本的python库，而是系统原本安装的python，所以无法import原先安装好的包。
- 检查现在的python版本
$ which python
输出结果为：
/root/miniconda3/envs/env_name/bin/python
说明当前环境确实是采用的该环境预设的python。
- 到这里我真的看不明白了，为什么虚拟环境的python版本显示没错，但是执行
python xxx.py时，实际却是用主环境的python版本。最后在系统的.bashrc文件中找到了可能的问题，其中有两行定义：
alias python3='~/miniconda3/bin/python'
alias python='~/miniconda3/bin/python'
这里已经对python和python3做了定义，指向主环境的python版本。或许就是这里导致在虚拟环境里，使用python xxx.py将调用主环境的python版本，而不是预设的虚拟环境的python版本。
- 发现问题之后，解决办法呼之欲出：
1）删掉.bashrc文件中的定义，重新source该文件生效。但可能会影响其他使用这台机器的人，或者哪天不知不觉又被设回来，到时候又要找半天错误，不推荐。
2）不能再偷懒了！以后都写清楚python版本！
$ python3.5 xxx.py
问题解决！
类似问题的其他解决方法：
https://blog.csdn.net/qiyou1998_/article/details/119004109
https://blog.csdn.net/weixin_39866963/article/details/110399239
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
