I. Description
Why not upgrade python 1.1 linux version
In 2008 python3 on the release of 2020 on January python2.7 1 Ri stopped updating , why the delay in removing the mainstream linux python2 comes python3.
We often hear about the server version of the operating system in order to ensure stability for the stable version of software generally only uses time-tested, instead of using the latest version. Do not upgrade python linux version is also for this reason it?
This is indeed python2 and python3 do not use the latest version of the main reasons, but not the main reason for the delay in linux python2 comes python3 not removed.
The main reason not to upgrade to python2 python3 is linux system itself python2 some software is written, not transformed into python2 can not be removed before python3 in the software, uninstall python2 force will cause the system to crash.
A typical example, yum is a python script that, when using the yum remove python2 python2 eventually want to uninstall to uninstall yum, yum and protected without the -f case can not be uninstalled (Error: Trying to remove "yum", which is protected).
Or in other words we, linux comes with python first goal is not to be used for the user, but to their use system tools.
System Tools is not the latest version needs no python3 demand system is not installed, much easier to understand. And in turn, I went to upgrade, change the system comes with python version, environment behavior is not encouraged, and this may affect the normal operation of the system.
When we issue 1.2 upgrade version of our need to care about python
On the one hand the system comes with python is not designed for our users, on the other hand we need the new features provided by the new version of python, so this time we will have to manually install the required python.
Here that the manual installation, not direct yum install, on the one hand to the release version of yum basic source verification tool on the system compatible, on the other hand to release the version on the yum source is generally not up to date.
Here that the manual installation, manually compile and install. Of course, not how hard manual installation, but we know yum install python python does not introduce new environment but directly overwrite the current python environment, manually compiled and installed in front of that should not be changed because the existing system environment so python to install to another directory go, that will introduce a new python environment.
At this point we should be concerned about two issues: First, the newly installed python will not affect existing python, and second, will not be affected by the impact of existing python when newly installed python use.
These two issues from the perspective of issues raised by the use and can be transformed into a technical point of these two issues: First, when the python program package which import directory import from, and second, will install the package to which the directory pip installation package.
Two, python manually compile the installation process
Download: https://www.python.org/downloads/
# To Python 3.8 , install / the Data / Home / OPT1 / python38 Case Study
# / data / home / opt1 soft link to / opt1, it might be two back catalog appear mixed # compiler and a conventional installation procedure as # extract the tar Python --zxf 3.8 . 0 .tgz # directory into the CD the Python - 3.8 . 0 # precompiled . / Configure --prefix = / Data / Home / OPT1 / python38 # compile the make # copy the compiled results to / OPT1 / python38 the make install
After installation is complete, the current two directories as follows:
Third, the concerns of answers
3.1 python program when the import package from which the directory import
python import program from those in sys.path import point when the packet.
By default sys.path [0] is currently being run python directory file is located (when not being executed file is empty), the other is currently used python command ../lib/ preset file (folder) .
对于用户而言有两个办法修改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变量。
