Linux手动安装新版本Python教程（CentOS）

一、说明

1.1 linux为什么不升级python版本

2008年python3就发布了，到2020年1月1日python2.7就停止更新了，为什么主流的linux迟迟不去除python2自带python3。

我们经常听说服务器版操作系统为了保证稳定性，对于软件一般都只采用经过时间检验的稳定版本，而不采用最新版本。linux不升级python版本是否也是这个原因呢？

这确实是python2和python3都不使用最新版本的主要原因，但并不是linux迟迟不去除python2自带python3的主要原因。

python2不升级成python3的主要原因是linux系统本身的一些软件是python2所写，在这些软件没改造成python3前都不能去掉python2，强行卸载python2会导致系统崩溃。

比如典型的，yum就是一个python脚本，当使用yum remove python2要卸载python2最终会要卸载yum，而yum受保护在不使用-f情况下是不能卸载的（Error: Trying to remove "yum", which is protected）。

或者我们换句话说，linux自带的python首先的目地并不是给用户用的，而是给自己的系统工具用的。

系统工具并没有最新版本的需求没有python3的需求系统就不装，这就很好理解了。而且反过来，我去升级、改动系统自带的python版本、环境的行为是不受鼓励的，这可能会影响系统的正常运行。

1.2 当我们升级python版本时我们需要关心的问题

一方面系统自带的python并不是为我们用户设计的，另一方面我们需要新版本的python提供的新特性，所以此时我们就有手动安装python的需要。

这里说的手动安装，并不是直接的yum安装，一方面发布到yum源上的版本基本都验证兼容系统上的工具，另一方面发布到yum源上的版本一般都不会是最新。

这里说的手动安装，是手动编译安装。当然并不是手动安装有多难，而是我们知道yum安装python并不会引入新的python环境而是直接覆盖当前的python环境，而手动编译安装由于前面说的不应改动系统现有python环境所以要安装到另外的目录去，亦即会引入新的python环境。

此时我们要关心两个问题：一是新安装的python会不会影响已有python，二是新安装的python使用时会不会受已有python的影响。

这两个问题从使用角度提出的问题又可以转化为这两个技术角度的问题：一是python程序中import包时从哪些目录import，二是pip安装包时会把包安装到哪个目录。

二、python手动编译安装过程

下载地址：https://www.python.org/downloads/

# 以python 3.8，安装到/data/home/opt1/python38为例
# /data/home/opt1软链接到了/opt1，所以后边可能会混杂出现两个目录
# 和常规的编译安装过程一样

# 解压
tar -zxf Python-3.8..tgz

# 进入目录
cd Python-3.8.

# 预编译
./configure --prefix=/data/home/opt1/python38

# 编译
make

# 将编译结果复制到/opt1/python38
make install

安装完成后，当前两级目录如下：

三、关心问题的解答

3.1 python程序中import包时从哪些目录import

python程序中import包时从sys.path指向的那些目录下import。

默认情况下sys.path[0]是当前被运行python文件所处的目录（当没有被执行文件时为空），其他是当前所使用python命令的../lib/预设置的文件(夹)。

对于用户而言有两个办法修改sys.path，一种方法是python会将环境变量PYTHONPATH（冒号分隔）解析加到sys.path，所以要加入的目录直接在~/.bashrc等文件中赋给PYTHONPATH即可。另外一种方法是sys.path本质就是一个列表，所以可以直接在python代码中使用sys.path.insert()、sys.path.append()进行添加。

3.2 pip安装包时会把包安装到哪个目录

在相当长一段时间内，当操作系统同时存在python2和python3时，我知道使用pip安装python2的库使用pip3安装python3的库。但同时存在两个python3时不知道怎样指示pip给自己想要的python安装库。直到几个月前前领导说可以这么安装：

# 假设系统现在有python36和python38两个python3版本

# 给python36安装faker库
python36 -m pip install faker

# 给python36安装faker库
python38 -m pip install faker

这确实是安装python库的一个解决方案，但这并没有正面回答 “pip安装包时会把包安装到哪个目录”这个问题，所以并不令人足够满意。同时我一直比较疑惑：为什么"python -m pip"和直接运行pip效果是一样的。直到直接查看pip文件内容后，这些问题都豁然开朗。

pip并不是一个二进制文件，而是一个python脚本；pip开头使用“#!”指示了运行该文件使用的解析器；"python -m pip"和直接运行pip最终都是执行pip包下的main函数，他们本质就是一个东西所以效果肯定也一样。

所以最终的结论是：pip把包安装到运行pip的解析器(pythonx.y)的"../lib/pythonx.y/site-packages"目录下；虽然未验证，但基本可以断定更本质是pip把包安装在其同级目录下，而pip的来源又取决于sys.path。

3.3 直接回答新旧版本python是否存在相互影响

经前边的分析可知，导入包和安装包都取决于sys.path而sys.path由python解析器自己决定，所以新旧版本python（在没有发生文件覆盖的情况下）不会相互影响。

更简单直白点，只要你用的python命令是你想要用的那个版本，import库和pip安装库都不会有问题。

四、虚拟环境

4.1 创建和使用虚拟环境

所有项目都使用一下python环境，会出现两个问题，一是久了就分不清哪些库是哪个项目所需要的不好整理依赖关系，二是不同项目可能依赖相同库的不同版本产生冲突。

所以当前主的做法是推荐不同的项目都使用一个独立的虚拟环境。

# 创建虚拟环境
# 含义：python3调用venv模块，创建一个名叫test_env的虚拟环境
# 本质上是把python38文件夹复制一份到当前目录下，并重命名为test_env
# 并不需要绝对路径，只是我这python38没加入环境，所以使用绝对路径
# 创建的虚拟环境默认是在当前执行创建命令的目录下
/opt1/python38/bin/python3 -m venv test_env

# 使用新建的虚拟环境
source test_env/bin/activate

# 退出上边激活的虚拟环境
# 本质是test_env/bin/activate中的deactivate方法
deactivate

# 删除虚拟环境
# 毕竟只是创建了个文件夹，所以要删创建的虚拟环境，直接把整个文件夹删除即可
rm -rf test_env

4.2 使用虚拟环境时到底修改了什么

在上边创建虚拟环境的截图中我们可以看到，激活之后发生了两个变化：python变成了虚拟环境的python，命令行前也多了虚拟环境的名称。

这两个变化是如何实现的呢，即然是"source test_env/bin/activate"会发生的，我们直接看test_env/bin/activate文件中做了什么即可。+

可以看到主要做了两件事，一是修改PATH变量把当前虚拟环境bin目录加到PATH变量的最前面，这就确保使用的python是虚拟环境中的python。

二是修改PS1变量把虚拟环境的名称加到PS1变量前面，这就实现了命令行前多了虚拟环境的名称。（使用conda时其效果与此类似，实现方法也是一样的）

再回头看deactivate，主要做的主要是与activate相反的两件事：还原PATH变量，还原PS1变量。