History: ver4開発 - mspp - mspp

ver4開発

UNIX版第1回開発会議（和倉温泉，2017-2-10~12）

開発言語

• 要件
  • C++に比べて、開発の敷居が低いこと
  • 質量分析やプロテオミクスに関するライブラリが充実していること

• Pythonを用いる
  • JavaとPythonが要件を満たす。初期の学習・導入コストの低いPythonを選定
  • 方針として、「python3.4以降 + Windowsへの導入が容易なライブラリ」を用いて開発する
    • つまり正確には、「UNIX版」ではなく「マルチOS版」の開発
    • 開発者の環境がWindowsという話は秘密だ

GUIライブラリ

• 以下のライブラリについて検討し、 Kivy を当面の試作用GUIに採用した。

ライブラリ	継続検討・不採用	備考
PyQT	不採用	ライセンスがGPL
PySide	不採用	LGPL。Winへの導入に挫折（nmake, cmake, qmakeについてエラーを吐き続け、Shibokenまでたどり着いて死んだ）（Macへの導入は容易）
		※脂肪肝を乗り越えると逝けそう
WxPython	不採用	LGPLライクな独自ライセンス。WinはVisual C++ 2010 が要る（Macは容易に導入可能で、すぐにHello, world!が出た）
		※VS2010でビルドされているWindows版Python3.4で動かそうとしたため。2.xは、Microsoft Visual C++ Compiler for Python 2.7を入れればインストールできる、はず。また、 python3.5 からはVS2015でビルドされているので問題は生じない、はず。(Windowsでのpython3系のバイオなりパッケージの利用には 3.5 以降に対応しているかどうかが分岐点になりそう。同じ理由でpython2.7系もWindowsでは避けたほうが良いという印象。参考)
PyGTK	不採用	GTK2用のバインディング。2011年4月で更新が止まっているので、チェックすらせず
PyGObject	不採用	LGPL。Winではpython3.4環境で、 source forge のバイナリ・パッケージを利用可能(このパッケージは、wxPython同様にCランタイムのバージョンの関係で、python3.5 以降では動作しないので注意。Anaconda の次バージョンから3.4がサポートされなくなる。また現行版のAnacondaも3.6がデフォルトで有効なので、 conda コマンドで 3.6から3.4に切り替える必要あり。)
Kivy	採用	MITライセンス。Windowsへのインストールはあっさりできた。(逆にMacでは、Mac port のpy35-kivyが依存ライブラリとは指定していない pygameを別途インストールする必要があった。)

• Cライブラリとの整合性
  • pure な python ライブラリではない場合、特に、pythonのC拡張を利用するGUIライブラリの場合、C拡張とGUIライブラリとで参照するCランタイムに不整合が生じると動作しない。なので、Windows上でお気楽に開発するには、python3.5以降に対応したバイナリ・パッケージが用意されているかどうかが重要となる。
  • Kivy はCython環境がCコンパイラ依存となるが、Windows版のビルドに、3.5より前では mingwを用いて、3.5以降にVS2015を採用し、2.7, 3.4, 3.5, 3.6用のバイナリを配布している。このあたりの対応の早さ、充実具合からも、今はKivyが旬であるという印象を受ける。
• その他
  • Kivyは、シングルウインドウでの開発となるので、デスクトップ(タブレットPC含む)アプリとしてのアーキテクチャとデザインについてよく話し合う必要あり。
  • pySide2はQT CompanyがQT5のパッケージに加えることを表明し、専従のpySide2開発者を置いていることから信頼がおけるが、時期尚早。だが、QT+python は、PyQtGraph(MITライセンス)が非常に魅力的なので、次バージョンの開発が軌道に乗るまではウォッチしても良いかも知れない。
  • pyGObjectは、Windows用バイナリ・パッケージがpython3.5に対応し、かつ、Macやタブレットへの対応に良い噂が聞こえて来たら、再検討しても良いかも知れない。