解决PyPlot.jl在JuliaPro套装下no working backend的问题

是 否 +2 论坛币

k人 参与回答

经管之家送您一份

应届毕业生专属福利!

求职就业群

赵安豆老师微信：zhaoandou666

经管之家联合CDA

送您一个全额奖学金名额~ !

立即领取

感谢您参与论坛问题回答

经管之家送您两个论坛币！

+2 论坛币

写Julia的伙计们应该大都接触过JuliaPro，这个套件某种意义上挺像Anaconda，还是很省心的。但这个套件在绘图方面有很大的问题（GadFly慢就暂且不说了），尤其是PyPlot这个通用大杀器经常，或者说从来都没能正常工作过……
no working GUI backend found or python GUI toolkit for xx (tk,pyqt4, etc.) is not installed

这两个报错可以说是通过JuliaPro调用PyPlot（默认这个包是安装了的）几乎必然遇到的问题，如果不知道原因的话确实很难解决，外网也没有针对性的解答，可以说是很多人弃用JuliaPro的原因了。楼主我花了半天多的时间彻底搞明白了这个问题的来龙去脉，就写一写，一来和大家分享下，而来自己也有个长期保存的笔记随时供查阅。

（第一个报错，虽然表现成warning但实际会导致完全不能work，是在using PyPlot的时候出现的；第二个则是在试图通过using PyCall; pygui(:tk)指定其他GUI容器的时候报的错）

1. why does PyPlot.jl not work?

PyPlot.jl这个包实际上是调用了python经典的matplotlib.pyplot接口。如果将这一调用过程按顺序写就是：Python --> PyCall.jl --> PyPlot.jl。上述两个报错实际上是在python环节报的错，PyPlot.jl这个包本身没有问题，而PyCall.jl这个包是最general的调用python的接口，最好玩的是，在JuliaPro套装下，它不是指定系统原本安装的python路径，而是在\\JuliaPro-0.x.x\\Python 目录下装了一个单独的Python环境（最新的JuliaPro 0.6.3.1对应Python 3.5.2）。这个Python环境有问题导致了PyPlot工作不正常。具体而言，是这个py环境缺少tkinter这个按理说Python 3.x都应该内置的标准库导致的。（大家可以去目录下执行python，试试import tkinter 或者import _tkinter试试）。而tkinter是matplotlib所依赖的GUI，缺少了tkinter，当然matplotlib.pyplot就无法工作，从而导致Julia里PyPlot.jl就会报错了。

网上这一类似问题提出可以通过在Julia prompt里使用pygui()指定特定的gui（如tk,gtk,pyqt5等），这一解决办法如果大家使用的不是JuliaPro而是一般的Julia distribution然后自己配置的原本系统就有的python的话，其实是管用的，因为咱一般正常自己安装的python 3.x都不会缺少tkinter。

2. how to fix it?

这个问题搞明白以后解决起来其实就很简单了，找准了Juliapro\\Python\\目录下那个python环境的版本，去pyhon官网下一个正常版的对应版本的python，覆盖安装就行了，原来的库什么的都不会丢失。安装完之后再用PyPlot.jl，就完全OK了。

3. miniconda & PyCall

这个问题看起来很简单，但楼主之所以折腾了这么久，主要是在Conda.jl的问题上折腾了半天。用Julia的伙计们应该知道Conda.jl这个包，完全是python下conda的翻版，用Conda.add()之类的命令就可以很容易管理Julia下挂载的Python包。但在JuliaPro里，大家如果细心，会发现除了刚才所说的PyCall自带的Python 3.x环境外，在JuliaPro-0.x.x.x\pkgs-0.6.3.1\v0.6\Conda\deps\usr\目录下还会发现另一个Python环境（惊不惊喜，意不意外，算上原本就有的python 3.6.x现在系统里已经有三个不同版本的python了）。这个环境通常是2.7的版本，套在一个miniconda里。如果大家原本就用Anaconda of Python套件的话，这个miniconda环境甚至可以不用Conda.jl管理而直接被Anaconda Navigator自动读取并管理（比Conda.jl方便太多）。

楼主之所以耽搁太多时间主要是因为一开始没有去仔细翻目录，没意识到这是两个独立的python环境，一直认为Conda.jl管理的环境就是PyCall调用的环境，所以反复通过Conda.jl调试，当然没有任何作用。大家用的时候一定要小心。

4. alternatives to plot in Julia

虽然现在PyPlot已经能用了，但楼主还是习惯于使用其他的一些绘图库。如果说整个Julia眼下最不趁手的内容还剩 绘图+debugger 的话，那么其实绘图已经基本解决了（Gadfly某种意义上就算对我这个R写了好久的人来说也仍然很是难用）。这里跟大家推荐一下我个人喜欢的一套绘图组合，安装的时候直接Pkg.add()对应名称就行了。

• GR：很有名的一个绘图框架，在多种语言包括python和C都有对应版本，语法友好，最大特点是速度特别快（甩Gadfly那反人类的1st time plotting几条街）。并且大家如果用Juno的话，这个也支持直接输出到plot pane里
• Plotly：也很有名，基于js的一个跨环境的库，最大特点是交互性强（GR相比之下就不能交互了）。默认的plotly不能输出到Juno的plot pane而是在浏览器里打开，但这个库下面的PlotlyJs库是支持直接输出到plot pane的
• Plots：这个与其说是绘图库倒不如说是一个general的接口（用的Recipes），本身不绘图，而是调用上面说的GR这几个库还有PyPlot之类的库进行绘图。最大的优点在于在不同的库之间尽量统一了语法，很general的语法，通过Plots调用其他绘图库接口，很傻瓜式的操作（切换绘图库/backends只要一个类似于gr()的函数）。
  

上面这几个大家可以玩一玩，多试几种选择。Plots有官网，http://docs.juliaplots.org/，很简明易懂的introduction，几分钟上手。

当解决了可视化的问题后，再配合Juno那勉强能用的debugger（至少比REPL强，能基本追到根本的错误位置），Julia在某种意义上已经可以取代matlab、R和python，单独完成所有研究用计算的任务了。（因为我们自己做研究的时候完全没有package参考，只能自己写，除了matlab的optimization工具箱之类的还经常用用外，其他的与其花时间找包还不一定靠谱，自己写的收益更高。当然，这个weighting还取决于各自人的编程水平。）

希望这条帖子对大家有一定帮助。欢迎交流！

扫码加我 拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

感谢楼主分享，在布置环境是遇到这些问题，也简单的补充两句，：）
1、JuliaPro 0.6.3.1自带的Python 3.5.2不仅不支持tkinter，而且库的路径设置是有问题的，在该环境下pip安装到site-packages的包居然找不到，应该是找带zip的那个一堆编译好的pyc目录了，按理说只要pip安装PyQt5就应该能工作了的；
2、解决这一问题覆盖安装有些暴力，只要指定PYTHON环境变量到其它Python发行安装就可以了，比如指定到Anaconda，包也够丰富，而且通过修改conda源解决安装包下载慢的问题，发现使用Conda.jl去走的话会将源修改为defaults，下载过程是非常蛋疼的。JuliaPro目录下的Python可以直接干掉，虽然在juliarc.jl中指定了这一目录，对运行完全没有影响；
3、Conda.jl包下设置了对Python的依赖，如果在执行Pkg.build("PyCall")，会去build Conda包，如果找不到全局Python，自己会下载miniconda进行安装，如果指定了全局Python是不会有这个步骤的，否则非常臃肿。

另外Pkg运行不是一般的缓慢啊，使用当下市场上个人PC主流的CPU、内存配置和固态硬盘，还是感觉出很卡，暂时不知道能否优化了。

entryman 发表于 2018-9-10 00:26
感谢楼主分享，在布置环境是遇到这些问题，也简单的补充两句，：）
1、JuliaPro 0.6.3.1自带的Python 3.5. ...

哈哈哈哈您的方法很好，我最开始为了应急就直接覆盖掉了，后来才直接重定向的PYTHON变量。确实这个方法更简洁，和原来的环境也统一了，更易于开发。

您提到的Pkg的问题我也有注意到。Pkg确实慢，不过我没有仔细研究原因（因为目前要求开发环境稳定，对包管理的需求不大）。而在1.0版本里已经彻底集成了Pkg的功能，速度也提上去了不少。然而1.0目前的问题是与0.6差别有点过大，各个包的生态还没有及时迁过来，特别是关键的一批，相应的Pro套装也因此尚未能建立起来，所以目前还没法把工程迁过去。此外，如果用JuliaPro+mkl，在我们组特定的需求环境下我测试的速度大约比纯1.0要快接近1/3，我们组一些计算密集的大型模型所以暂时还不想迁过去。我觉得这些都是Julia 1.0应当尽快解决的问题，否则很影响社区的未来发展

特别地，very personal的一点感受是，如果0.6支持从1.0开始的NamedTuple类型，那么我还真的没有什么动力在未来迁项目过去呢

毕竟0.6对于同时有matlab和C基础的人来说上手成本几乎为零，性能又足够高。但1.0感觉受python社区来的开发者影响好大，为了精简内核符合语言设计美学干掉了一大批研究中常用的方法，语法风格也变得更不像matlab，使得Julia 1.0反倒对主要用户群体中占比很大的研究人员而言易用性降低了不少。毕竟相当多的学者之前还是主要在matlab、R这一类平台上工作并且缺乏很系统深入的程序设计训练，不能奢求所有研究人员是程序员，都具有在所有语言中快速切换学习的能力。这不公平，也不高效。比如我们组的很多人虽然很羡慕Julia的强大，但目前还是没有动力去学习，对于他们而言理解并且自由运用matlab就已经很麻烦且耗时了。

entryman 发表于 2018-9-10 00:26
感谢楼主分享，在布置环境是遇到这些问题，也简单的补充两句，：）
1、JuliaPro 0.6.3.1自带的Python 3.5. ...

请问具体如何指定自己的Python路径？环境变量吗？