什么是虚拟环境
我们在使用Python的时候,通常用pip
来进行包管理。比如我们要安装一个叫requests
的库,那么我们就会采用以下命令去安装:
pip install requests
那你知道,这个requests
被安装到哪里去了吗?
其实,这个requests库被安装到 Python安装目录/Lib/site-packages下面。要知道,site-packages是一个全局包路径
。
啥意思呢?就是说,我安装的requests
这个库对这台电脑的这个版本的Python都生效。
那这样会造成一个问题
:
如果requests在1.0版本和1.1版本发生了较大变化,比如:
1.0版本的时候有个方法叫
requests.get
,到了1.1版本,这个包改名叫requests.got
, 然后还支持了不少新特性
。
如果我有一个很老的
项目,一直用的是1.0的版本,而我现在写了一个新项目,又想用到1.1版本的最新特性。
那我如果只有一个版本的requests,我就没法兼容新项目
和旧项目
了。
所以我们有了虚拟环境的概念,其实也可以说是隔离环境
。说简单点就是,这个python的库管理跟随你的项目走,你项目里就算用到100个库
,也不会给你装到全局去,这样就隔离了全局的库。
安装virtualenv
而达到这样的目的,都是基于一款python的库: virtualenv
。(它支持python2和3)
pip3 install virtualenv
tips: 有的python库,他不一定是给python代码调用的,你可以把它想象成一个可执行程序
,比如我们常用的gunicorn,虽然是通过pip安装,但是安装好了之后它是一个可执行程序
。
我们可以在Python安装目录的Scripts看到这些可执行程序
创建虚拟环境
安装好virtualenv以后,我们就可以来开辟一个虚拟环境,用于隔离全局的库了。
virtualenv venv
在我们的项目根目录
下执行这个命令,可以看到一些提示:
可以看到它帮我们创建好了虚拟环境,并带上了pip和setuptools
启用虚拟环境
我们根目录下会多一个venv的文件夹,里面有点东西。
可以看到,基本上这就是一个小的"包管理目录"呀
别急,我们还得先激活这个虚拟环境
。
- Mac/Linux
source venv/bin/activate
- Windows
venv\Scripts\activate
其实可以看到,venv的Scripts里面有个activate.bat(激活虚拟环境脚本),而Unix系统下自带source,所以有些区别。
如果前缀带上了venv的标识,说明你成功了
接着你就可以在虚拟环境畅游了,你所有安装/卸载的包都会在venv目录下被安排的服服帖帖的,不会被影响也不会影响
到全局的库。
退出虚拟环境
source venv/bin/deactivate
- Windows
venv\Scripts\deactivate
用deactivate就好了,这样你的包管理又回到了全局,venv标识也消失不见了。
带不带.bat都是一样的,不需要纠结
其实这个很像node_modules
,node_modules在项目的根目录生成,并通过package.json进行包的版本管理
,不影响全局模式,非常好用。
简单的说就是各玩各的,互不干扰
!
标题从3分钟->5分钟,最后改为几分钟,你读完了么?反正我是读完了!