python多环境管理一（venv与virtualenv）

一、背景

我们经常会遇见这样的场景：

1、各个项目使用的python版本不相同

由于Python的解释器版本众多，各版本之间差异非常大。特别是python2和python3，互不兼容。

有些项目可能用的python2.7，有些项目可能用的是python3.6，有些则使用的3.8等，但是它们却需要运行在同一个服务器环境中。（docker除外，docker容器可以隔离不同的项目环境。）

2、系统依赖自带的解释器

系统的一些服务组件一般也会依赖Python环境。不同的Linux发行版自带的Python也不同。如ubuntu16自带2.7和3.5版本, Centos7依赖python2.7。而系统很多组件都依赖自带的解释器，比如yum等，你不能轻易删除这个版本，一旦删除或者更改都可能造成系统出问题。

3、依赖默认的解释器路径冲突

比如Centos7系统自带的python是2.7，系统很多组件比如yum依赖的都是2.7这个版本。但是我们发现这些工具开头使用的都是：#!/usr/bin/python。

而一些新的使用python开发的服务组件，它们依赖的确实python3.6以上的版本，但是它们一些代码开头用的也是这个引用：#!/usr/bin/python。

它们都是用python这一个引用，却没有使用python2、python3这样分开，这就很容易导致它们的一些python引用冲突。

4、依赖冲突。（最常见）

我们都知道python的软件包依赖经常是个很头疼的问题，经常因为这个问题导致到家在安装一些python环境或者服务组件时失败。

而不同的python解释器版本，对软件包依赖库的管理也是个问题。

比如sqlalchemy这个包，有些项目使用的python2.7版本，它需要依赖这个库，有些项目使用的python3.6版本，它也需要依赖这个库，有些项目使用的python3.8版本，它同样也需要依赖这个库，

但是头疼的是，这三者它们依赖的这个包版本还不一致。sqlalchemy从0.1-2.0有众多版本。

这时候如果你在系统上直接使用pip install sqlalchemy的话，它只能选择安装一个版本，但是这样其他两个项目是无法使用这个版本，就会出现依赖冲突的问题。

由于 Python 的依赖库管理是中心化的，而且大版本上的不兼容且长期并行，就出现了这么一个独特的话题。

你的环境隔离了吗？

二、多环境隔离解决方案

那么有没有一个终极的解决办法能在管理不同解释器版本的同时控制不同的包环境呢?

有的，Python 社区已经涌现了众多这种工具。

Python 多环境隔离，可以让你的每个项目拥有独立的依赖库，即 site-packages。

三、venv

为什么把 venv 放在第一个，因为它是自 3.3 版本之后添加的官方库，自 3.6 版本之后，成为官方推荐的多环境管理工具。也就是说，你不需要安装任何第三方库就可以实现多环境管理了。

注意：python3.3版本之后自带的模块，只支持3.3版本之后的，不支持2.x

1、虚拟环境管理

使用venv创建虚拟隔离环境：

python3 -m venv /data/myproj

它会创建/data/myproj目录，下面如下：

ll /data/myproj

如下图：

bin下面是pip、python等一些可执行环境，

pyvenv.cfg 是我们的配置文件，为什么叫 pyvenv，因为这个库的前身就叫 pyvenv。

而我们的 site-packages 就在 lib 目录下。

激活虚拟环境:

cd /data/myproj source ./bin/activate

如下图，命令行最前面会显示环境名。

激活