Ubuntu 16.04升级Python3.5到Python3.6后带来的问题

背景介绍：
Ubuntu16.04默认的Python版本是2.7（python）和3.5（python3），而我更喜欢用Python3.6，而且anaconda目前默认支持的也是3.6，所以就网上找了一个升级的方法升把Python升级到了3.6.而且设置了python3的默认为python3.6

升级3.6：
https://blog.csdn.net/lzzyok/article/details/77413968
并且使用了update-alternatives来配置具体使用哪个python3版本

然后安装anaconda：
anaconda的安装比较简单，就是在官网上下载anaconda3版本对应的sh文件，然后安装。最后将环境变量写入.bashrc中（zsh需要写入.zshrc文件中）。至此因为环境变量的改变，导致目前默认python已经变成了anaconda的Python3.6

问题Ubuntu自带的终端打不开

重启电脑后terminal打不开，在search打开XTerm后，输入gnome-terminal发现有“ImportError: cannot import name '_gi'”问题。网上找了下原因，其实拷贝之前的35版本的文件为36版本的即可。

indicator-sysmonitor打不开

这个软件是在任务栏中监视cpu/内存/网速等的工具。
因为也是无法使用，所以在终端中输入indicator-sysmonitor命令后看了下错误提示：
ImportError: cannot import name '_psutil_linux'
其实这个问题和上面那个问题很类似。
先用find搜索了下：
sudo find /usr/lib/python3 -name '_psutil*'
/usr/lib/python3/dist-packages/psutil/_psutil_posix.cpython-35m-x86_64-linux-gnu.so
/usr/lib/python3/dist-packages/psutil/_psutil_linux.cpython-35m-x86_64-linux-gnu.so
找到这个文件位置后，同样复制了一份36版本的文件出来。问题就得到了解决。

撤销anaconda的环境变量

经过这几个问题，我发现Ubuntu上很多软件对Python版本的依赖比较强，所以考虑了下，取消设置anaconda的环境变量，只是使用别名来方便调用：
# added by Anaconda3 installer
#export PATH="/home/dd/anaconda3/bin:$PATH"
alias pyana="/home/dd/anaconda3/bin/python"
并且增加对python命令的版本切换管理：
sudo update-alternatives  --install /usr/bin/python python /usr/bin/python2.7 1
sudo update-alternatives  --install /usr/bin/python python /usr/bin/python3.5 2
sudo update-alternatives  --install /usr/bin/python python /usr/bin/python3.6 3
通过update-alternatives --list python可以查看
通过sudo update-alternatives --config python可以选择
另外sudo update-alternatives --config python3切换回python3为3.5版本

接下来的使用

因为Python3.6版本是为了我个人的代码工程用的，所以就不在系统中默认使用了。以后安装软件的时候还是继续使用Ubuntu的默认依赖。只是在自己的代码中使用anaconda的Python。比如在IDE中配置好Python的解释器。
如果需要在命令行中使用可以通过pyana或者
通过source activate来激活anaconda的环境。比如先查看
./anaconda3/bin/conda info -e
# conda environments:
#
base                  *  /home/dd/anaconda3
然后再激活
➜  ~ source ./anaconda3/bin/activate base
(base) ➜  ~ 

也可以创建一个新的环境：
./anaconda3/bin/conda create -n anapy anaconda
然后就可以切换环境了。

需要注意的一个问题是：
➜  ~ conda
zsh: command not found: conda
➜  ~ ./anaconda3/bin/conda info -e
# conda environments:
#
base                  *  /home/dd/anaconda3
anapy                    /home/dd/anaconda3/envs/anapy

➜  ~ source ./anaconda3/bin/activate anapy
(anapy) ➜  ~ python -V
Python 3.6.5 :: Anaconda, Inc.
(anapy) ➜  ~ pip -V
pip 10.0.1 from /home/dd/anaconda3/envs/anapy/lib/python3.6/site-packages/pip (python 3.6)
(anapy) ➜  ~
(anapy) ➜  ~ source deactivate
source: no such file or directory: deactivate
(anapy) ➜  ~ cat ./anaconda3/anaconda.sh
# added by Anaconda3 installer
export PATH="/home/dd/anaconda3/bin:$PATH"
(anapy) ➜  ~ export PATH="/home/dd/anaconda3/bin:$PATH"
(anapy) ➜  ~ source deactivate                       
➜  ~ 
从环境中退出时也需要指定deactivate的路径。

➜  ~ whereis deactivate
deactivate: /home/dd/anaconda3/bin/deactivate



评论

发表评论

此博客中的热门博文

Bazel WORKSPACE文件编写

WORKSPACE文件主要就是命名workspace以及声明外部的依赖，这就包括外部依赖的获取方式及获取方法。 外部依赖 https://docs.bazel.build/versions/master/external.html WORKSPACE文件告诉Bazel如何去得到其他的工程源，然后package中的BUILD文件就可以根据WORKSPACE中的外部target名字写依赖关系。 先举个例子来看下在本地的两个工程如何实现依赖关系： / home/ user/ project1/ WORKSPACE BUILD srcs/ ... project2/ WORKSPACE BUILD my-libs/ project1希望能依赖project2/BUILD下的target :foo，需要指明project2可以在 /home/user/project2 中被找到，而且接下来project1的BUILD就可以写依赖关系： @project2//:foo WORKSPACE文件允许用户的目标依赖其他文件系统的目标或者从网上下载的目标。 WORKSPACE文件的语法和BUILD文件一致，不过会用到一些特定的内置rule，细节参考下一个章节的内容。 一共有三种外部依赖的主要类型： 依赖于其他Bazel工程 根据这个Bazel工程所处的位置不同，调用不同的内置rule来获得： local_repository ：本地 git_repository ：git仓库 http_archive ：网络下载 假如现在有个工程 my-project/ ，需要依赖与另一个工程 coworkers-project/ 。这两个都是Bazel工程，那么需要在 my_project/WORKSPACE 下添加： local_repository ( name = "coworkers_project" , path = "/path/to/coworkers-project" , ) 然后对于coworke
阅读全文

Bazel的概念和技术

这个文章应该是要长期不定时更新的，因为涉及到的很多概念的理解，技术的理解，这些内容仅通过初次接触Bazel是远远不到位的，甚至不能保证下面缩写内容的正确性。 从整体上来看Bazel的实际对项目的控制和管理是长这个模样的： 1、Bazel对于源码的组织在一个文件夹之下称之为 workspace （这个文件夹下面包含一个WORKSPACE文件） 2、源码文件被一系列的分层结构的 package 所组织 3、每一个package就是一个包含一系列相关的源码文件以及一个BUILD文件 4、BUILD文件指示了如何从源码中输出build结果 开始一些干货： Workspace 其实workspace就是一个文件夹。这个文件夹下面包含一个 WORKSPACE文件，以及一系列的源码文件，这些源码被package组织起来，也就是在各个package中存在的BUILD文件。 而且随着在workspace中进行bazel build这样的操作（可以不在workspace root目录下build），会在workspace的root目录下面产生诸如：bazel-bin  bazel-genfiles  bazel-java-tutorial  bazel-out  bazel-testlogs这样的输出文件夹（软连接） 当然简单的项目中WORKSPACE文件可以是空文件，但是对于正常的工程来说，这里面要写一些整个工程的 外部依赖 及其书写rules： Workspace Rules ，这两块内容会在下一篇博文中介绍。 Package 在workspace中，代码是被一个个的package所管理，每个带BUILD文件的文件夹就是一个package，这里面包括了自己的源码文件以及规定了内外依赖关系。 package将自己所在的目录下面所有包括子文件夹下面的文件都视为属于自己package的。除非子文件夹下面有存在BUILD文件，那么这个子文件夹就是一个新的package。 Target package是一个容器，那么这个容器里面所包含的元素就是target。大部分的target都属于这两个最主要的类型：files和rules。还有一种target叫package groups。 对于file类型的target，主要
阅读全文

Bazel BUILD文件的编写

除了公共部分BUILD文件可以使用的规则外，还有一些与语言相关的build rule https://docs.bazel.build/versions/master/be/overview.html 这里根据不同的语言，来写整理。 Java Bin rules java_binary java_binary( name ,  deps ,  srcs ,  data ,  resources ,  args ,  classpath_resources ,  compatible_with ,  create_executable ,  deploy_manifest_lines ,  deprecation ,  distribs ,  features ,  javacopts ,  jvm_flags ,  launcher ,  licenses ,  main_class ,  output_licenses ,  plugins ,  resource_jars ,  resource_strip_prefix ,  restricted_to ,  runtime_deps ,  stamp ,  tags ,  testonly ,  toolchains ,  use_testrunner ,  visibility ) build一个java的jar文件，并且套上一个shell的脚本来辅助运行。 隐式的输出target： name.jar name-src.jar name_deploy.jar：这个比较特殊，必须显式的build才会生成，比如 bazel build //package:target_deploy.jar name_deploy-src.jar Lib rules java_import java_import( name ,  deps ,  data ,  compatible_with ,  constraints ,  deprecation ,  distribs ,  exports ,  features ,  jars ,  licenses ,  neverlink ,  proguard_specs ,  restricted_to
阅读全文