GoCon 2019 Autumnに参加してきた
はじめに
今回はGo Conference 2019 Autumnへ参加するにあたり,Wantedly株式会社様よりスカラシップによる支援を頂きました.大変感謝しております.また,運営の方々,大変楽しくためになるカンファレンスでした.次回以降も是非とも参加したいと思っております.本当にありがとうございました.
なお,本記事では自分が面白いと思って聞いたセッションについて掲載しています.全体の総括ではありませんのでご了承ください.
初めて参加してみて
Go Conの存在については以前から知っており面白そうだと感じては居ましたが,開催地が遠かったのもあり,今回が初参加となりました.
これまでのことは存じ上げませんが,今回の会場はどこも登壇者と聴衆の距離が近く,一体となって盛り上げていくような感覚がありました.僕がスカラシップ用のバッジを身につけていたのもあるとは思うのですが,話したことない方からも「学生の方ですか?」とかお声かけ頂いたりして,大変ありがたかったです.
セッションはどれも聞き応えがありましたが,ただの全体のまとめをしがない学生が書いても意味は無さそうです.そこで,今回は僕自身が聞いてこれから活かしていけそうだなと思った話や,純粋に興味があり面白かった話などに絞っていくつかピックアップしたいと思います.一応万全は期していますが,内容等に間違いがあればこっそり指摘して頂けると修正します.
面白かったセッション
全て自分で聞きに行ったセッションです.資料のURLはTwitter等で知ったものについては載せています.
1. Go GC algorithm 101
まずは最初のセッションである,Wantedlyの20卒内定者taxioくんの発表です.説明が非常に分かりやすく,知見として有益でした.一時期Pythonのプログラムのメモリリークに悩んでいたこともあって,自分でGCについて多少調べたりしていたのですが,入門として非常に優秀なスライドだと思います*1.
特に,GCというものは文章で書かれてもイマイチ理解出来ない部分があり,視覚的に図で示されるとなんとなく理解しやすいように感じます.まだまだ奥深い話が無限にある世界だと思うので,彼がもっと詳しくブログを書いてくれることを期待しています.
発表後に上がった質問
さて,本Sessionの内容はもうスライドとしてまとまっており,これ以上僕が言うことは何もないので,会場で出た質問とそれに対する発表者による回答をざっと上げていきます.
- Q: 世代別GCが美味しいケースはどこ?Goでは通常スタックに確保されるはずで,ヒープに短命なオブジェクトが漏れてくるケースは珍しいのでは?
A: Rick氏の発表*2をもう少し見る必要がある - Q: 短命なオブジェクトでヒープに来る物はどんなもの?
A: エスケープ解析などによって決まり,詳しくないのでなんとも言えない. - Q: Bitmap markingでCoWとの相性が上げられているが,GoでフォークしてCoWが活かされるケースはあるか
A: 調べたがはっきりした言及がない.他の言語などで有効なことは分かっており,一応括弧付きで記載した. - Q: Concurrent Mark & Sweepを選んだ理由は?
A: 最初はCopy GC(フラグメンテーションを抑える)などが検討されていたが,Go 1.4でのCからGoでのセルフホストへの移行との兼ね合いもあり,実装コストと効果の面から選ばれた. - Q: JVMなどではGCアルゴリズムを変更できるが,Goでもそういうオプションを付ける展望はあるか?
A: Issueなどで見たことはない
この中で個人的に気になったのは一つ目と二つ目で,これらはお互いに関係しているのですが,突き詰めると
- Goにおいてヒープにアロケーションされるのはどのようなときか
という問いに収束します.ヒープにも短命なオブジェクトのアロケーションが頻繁に起きるなら,世代別GCも効果がありそうに思えますし,そうでないならむしろなぜそのような検討がされているのか気になるところです.
Goでヒープにアロケーションされるのはどのようなとき?
Google先生に聞いてみたところ,このブログがヒットしました.
この記事自体は
これを参考にしているようです.本文からいくつか引用すると,
ポインタはスタック割り当ての阻害要因なので可能なら避ける。
ポインタを使うとほとんどの場合ヒープ割り当てになってしまう。
とか
スライスはサイズが動的でコンパイル時には未決定なのでバックストア(スライス内のポインタが参照する先)の配列がヒープ割り当てになる。
とか
戻り値で文字列やスライスを返す関数には注意。
例えば func (t Time) Format(layout string) string の戻り値のstringの値(正確にはバックストアの配列)はヒープ割り当てになる。
とか書いてあり,Goの文脈に置いても,それなりにヒープへのアロケーションはありそうという感想を持ちました.
結局Goで世代別GCは効くのか?
「go generational gc」とかで検索していると下記のGoogle Formに行き当たりました.
ここでは世代別GCの可能性について,
- 世代別GCの良いところはSTWの時間を短く出来るところ
- ただしGoは並列でGCをするので,STWの時間は世代のサイズに依存しない
- GoではGC時間を最小化する代わりに全体の実行を一次停止するのではなく,異なるコアで並列に実行することの方が良いと想定している
- とはいえGCが並列で行う必要のある仕事を減らすことで大きな価値をもたらす可能性もある
- 今この仮説について検証を進めている
ということが述べられているようです(これが2017年).
これを踏まえて
を読んでみると(これが2018年),
- 大きなヒープサイズに対してはそう悪くない
- ただ私たちのベンチマーク上ではあまり良い結果を示さなかった
- 世代についての仮説がGoに当てはまらないわけではなく,若いオブジェクトはスタック上で生きて死んでいくというだけ
- そのため,他の言語よりも世代別GCの効果が弱い
と述べられているようです.
結局,Goのコントリビューターたちは色々試した上で,今の実装に行き着いているようです.ただし特定のケースでは別の方法のほうが良いというようなことはあり得そうなので,質問でも上がっていたように「GCアルゴリズムを可変にする」というような仕組みがあっても面白いのかなと思いました.
2. Go で"超高速"な経路探索エンジンをつくる
次にDeNAの井本さんのセッションで,経路探索のアルゴリズムとGoにおける実装上の高速化の話です.井本さんの説明が非常に丁寧でわかりやすく,アルゴリズムの話・実装の話のどちらもしっかりと納得しながら話を聞くことができたように感じました.特に実装の話においては,Goにおけるsliceとmapの実装方法を説明した後に,改善の方法と結果を示すという方針で話が組み立てられており,わかりやすかったです.
LT・セッション等で見かけがちな「でもそれそちらのドメインではの話でしょ?」みたいな高速化ではなく,本当に基礎的な,ちょっとしたGoのコードからでも実践できるようなプラクティスが述べられていることが特に素晴らしかったです.sliceやmapを一切使わずに書くことなんて普通無いと思いますし,それらを使う上で簡単に実践できるプラクティスが背景知識と共にまとまっているのは,知見として非常に素晴らしいと思います.
また,これは会場の様子を映像と音声でお伝えできないのが悔やまれるのですが,登壇者である井本さんが非常に落ち着いた声でゆっくりと説明されており,聞き取りやすかったというのも大きかったです.人は緊張すると早口になったり,重要なところで噛んでしまったりするものです*3.落ち着いて話されているセッションというのは聞いている側も安心できるので,こういうところも見習っていきたいと思いました.
発表後に上がった質問
結局mapが遅いので,見方を変えてmapを諦め二次元配列でのアクセスにするという話でmapの高速化の話は終わっていました.それについて,メモリ局所性に基づいた高速なハッシュマップの実装があるはず(?)というような質問が上がっていたのですが,僕自身の知識の無さであまり理解出来なかったため,省略します*4.
アルゴリズムの重要さ
今回はGoConということで,みんなGoの実装についての注目度の方が高いと言うことは間違いないと思います.実際僕もあまりアルゴリズムへの造詣が深いわけではないので,ぱっと使えて分かりやすいsliceやmapの使い方に目が行ってしまいがちです.
しかし,最も重要なのは「どういうアルゴリズムを選択するか」という部分のはずです.この発表でも前半でアルゴリズムの選択について触れられていますが,実務では単に最速のアルゴリズムを探すわけではなく,実用性を考えて,要件に合うものを使うことになるはずです*5.今回のDeNAさんでの要件だと「渋滞の反映」みたいな,事前計算時間に対する要求があったはずです.何らかの制約がある中でアルゴリズムを選択するのは,どういったところでどういった経験・知識を積むと良いのか知りたいです.競技プログラミングも近い物だとは思いますが,やはり少し実務とは違う部分もあると思っているので.
3. Write Container Runtime in Go
最後に@tomocyくんの発表です.資料が上げられていないので, https://gocon.jp/sessions/write_container_runtime_in_go/ の説明欄から引用します.
昨今では、DockerやKubernetesは多くのプロダクションで採用されています。そしてコンテナランタイムはこれらの技術を支える、正に中心的な技術です。このトークではrunCなどの各コンテナランタイムのGoのコードを紹介しながら、コンテナランタイムについて話します。またOCIが定めるOCI runtimeについてを、自作のコンテナランタイムをそれに準拠させながら話します。このトークの後で実際に自身の手でコンテナランタイムの自作、OCI runtimeへの準拠ができるように、GitHubにログ付きのレポジトリーを公開する予定です。
このセッションではContainer Runtimeを""Goで""実装するという部分に重きが置かれており,実際に彼が実装したコードを示しつつ,OCI Runtime Specに沿って実装を進めていくという形で発表が行われました.
実は彼もWantedlyのスカラシッププログラムで来ていたのですが,自己紹介でおもむろに「実は今日登壇します」と言い出して,全員の度肝を抜いたという裏事情があります.僕は開催前からこのセッションを見る予定をしていたので,まさか同じスカラシップの学生が登壇者だとは思わず,驚きと焦燥でかなり動揺してしまいました……
2019/11/1 0:00 追記
tomocyくんが資料を上げてくれました!
彼のアフターレポートはこちら
Container Runtime
コンテナランタイムの実装として最も一般に普及しているのは,おそらくDockerが使用しているruncです.これについては以下の資料が分かりやすかったです.
上記資料の4ページ目にあるように,Dockerのような高レベルランタイムは,runcという低レベルなコンテナランタイムのインターフェースであると言うことが出来ると思います.そのため,Dockerの仕様に沿ったコンテナランタイムを実装すればruncと差し替えて使うことも出来るわけです*6.
OCI Runtime Spec
コンテナランタイム実装について,標準的な仕様を定義しているのがLinux Foundation傘下にあるOpen Container Initiative(OCI)です.runcの開発元でもあります.
ランタイムの実装者はこれを見ながら実装するのですが,実はこの仕様では5つの操作方法と,それに対して何を返し,何をするべきかが記述されているだけで,内部の実装をどう書くかには一切言及がされていません.その5つの操作方法が以下です.
操作名 | コマンドと引数 | 何をするべきか |
---|---|---|
State | state <container-id> |
コンテナの現在の状態を返す |
Create | create <container-id> <path-to-bundle> |
コンテナを作る(実行はしない) |
Start | start <container-id> |
コンテナに与えられているコマンドを実行する |
Kill | kill <container-id> <signal> |
コンテナにシグナルを送って止める |
Delete | delete <cintainer-id> |
Createされたコンテナを削除する |
上記の5つのコマンドを実行できるCLIを用意すれば,OCI Runtime Specに則ったランタイムを作れる,というわけです.
どう実装するか
runcと同様,tomocyくんはLinuxの機能(Namespace,cgroup,chroot/pivot_root…etc)をふんだんに利用したランタイムの実装をしたそうで,実際に起動したプロセスが,どのようにホストから隔離されてコンテナとして動作していくのかを順に追って説明してくれたので,仮想化の機能についてそう詳しくない僕でも話について行くことが出来ました.
また,Goでの実装方法についても
- urfave/cliで簡単にコマンドを実装する
- Dependency Injectionを使ってテスタビリティを上げ,CLIを薄く保つ
_linux
などのプレフィクスをファイル名に付けることでBuild ConstraintによってOSごとにビルドされるファイルを変える
などの基本的な,しかし実際によく使われている手法を紹介していました.本当に短いコードで色々示してくれるので,あれっもしかして簡単なのでは?とちょっと思わせてくるあたりが凄かったです.
「車輪の再発明が好き」
この発表で特に印象に残っているのは彼が言っていたこのセリフです.普通だと「それはもうあるし再実装するのは無駄だよ」とか周囲から言われて止められがちなのですが,彼はあえてそういった車輪の再発明をGoでやるということに情熱を傾けているそうです.昼食時にもGoのhttp.Clientを自前で実装し直してみている話とかを聞かせてくれました.
普段僕は「あるものは使う」というスタンスなので,必要があればサードパーティーの実装を躊躇なく使いますし,言語の持つ便利な機能やモジュールがあれば,同等の機能を自分で実装することはほとんどありません.しかし,逆を言えば
- そういった機能がどのように実現されているのか
- 実現するにあたってどういうところに苦労するのか
といった部分をほとんど知らないままでいることになります.例えば今回のコンテナランタイムの話にしても「Namespaceとかchrootとか使ってるらしい」みたいなことは知っていても,どういう順番でそれらが使われていくのか,どのように使うのかといった情報はほとんど知りませんでした.こういったことが他の様々なものに対しても同様に起きていると考えると,自分の無知に絶望してしまいそうです*7.
たまにはそういった,よく使うけどどう動いているのか知らないみたいなものについて,コードリーディングしたり実際に手を動かしてみるなどしてみると,より自分の世界が広がるかなと感じました*8.
発表後に上がった質問
- Q: Dockerを動かすために必要な物にはどういうものがある?
A: DockerはOCIあんまり守ってないので,イメージのディレクトリレイアウトも違うし,Dockerのためにいいかんじに動かすコマンドが必要 - Q: 強いランタイムはどういう実装をしている?
A: 例えばgVisorはセキュリティ特化で,一部ハイパーバイザのようなことをしているらしい.速度はトレードオフかもしれないが,リソース分離をしっかりやっている.評価軸に沿ったランタイム選定をすれば良い. - Q: Linux特有の機能を使いまくっていて良い.Mac使ってるみたいだけど,Linuxのやつをどう開発した?
A: 開発にはエディタの機能を,動作検証はコンテナの中でやった
特に最後のLinuxの機能を使いまくっているのにMac使いってどういうことなんだと思っていたのですが,どうもVSCodeでは環境変数GOOS
によって補完される内容が変わるらしく,これを使って実装していたとのこと.確かにGOOS
設定できるようにしてくれというIssueがあり,実際に対応されているようです.
コンテナの検証をコンテナの中でやるというのも,会場の笑いを誘っていました(笑)
tomocyくんの名言(迷言)要約集
- コンテナランタイムって作ってもあんまり感動がない
- もっと感動が欲しい人はDockerコマンドから叩けるようにしよう
- Dockerから使えるようにすればさすがにお母さんも感動してくれるはず
彼はおそらくとんでもない化け物だと思います(褒めてる).
Goコミュニティにどう貢献していくべきか
残念ながら僕はスーパープログラマではないようなので,Go言語そのものや,Goでの開発に対してとてつもないインパクトのある何かを残せるとは思っていません*9.では,そういう自分が何をやっていけるかというと,やはり
- Goをこういうシチュエーションで使っている
- こういうところが便利でこういうところがつらい
- こんな便利なものを作ってみたよ,実はGoで書いてるよ
みたいな,Goを使うことについての対外的な情報公開かなと思っています.結局ユーザがたくさん居ても情報が出てこないとその活発さは可視化されないし,コミュニティが活発で無いと新規ユーザも増えないと思っています.Goの恩恵をたくさん受けているので,恩返しというと恩着せがましいですが,コミュニティにとってより良い影響を与えられるように頑張っていきます.
まとめ
Go Conferenceは実務でバリバリGo書いている人でなくても,得られる知見がたくさんあります.開催地が遠くてお金が……という場合にも,何社もスカラシップスポンサーとして学生を支援してくれています.ちょっとでも気になっているなら,次回の参加を検討されてみてはいかがでしょうか.
次か次の次くらいのGo Conferenceでの登壇目指して精進していきます.同じく登壇を目指す方々,対戦よろしくお願いします.
合わせて読みたい
*1:PythonのGCは主に参照カウント方式を,補助的に世代別GCを使用しているのでGoのものとはかなり異なります
*3:これは僕の話です
*4:行列演算の例で有名な同じ行の要素に連続してアクセスした方が早いという話に近い物だと思うのですが,短い質問時間の中では僕の理解が追いつきませんでした.
*5:実務でそんなにアルゴリズムをゴリゴリやったことがないので想像で書いています.場合によるとは思います.
*6:これを利用したのが(Docker 18.09までで)コンテナからGPUを使用できるようにしたnvidia-dockerです
*7:例えばGoのmapやsliceの詳しい実装についても井本さんのセッションでこの日初めて知りました
*8:そういう意味で,Wantedlyのスポンサーセッションで紹介されていたGopher's Code Reading Partyはとても良さそうです
*9:これは諦めていると言うことと同義ではありません
公開さえすればいいってもんじゃない
TL;DR
- 研究で開発したツールを公開するのはとても良いこと
- 頼むから必要な依存関係の情報を残してくれ
- 頼むからREADMEを書いてくれ
- 頼むからライセンスを明記してくれ
- 頼むからDockerイメージになんでも突っ込まないでくれ
はじめに
これはあくあたん工房お盆休みアドベントカレンダー7日目の記事です.
今日は開発者向けではなく,研究者向けの話をします.主にコンピュータサイエンスの話になりますが,ソフトウェアを書く必要のある分野であればどれもそう変わらないだろうと思います.
研究でソフトウェアを書いている人,それをGitHubで公開している/しようとしている人へ向けて書いています.僕の専攻分野,研究内容による影響でこの記事の内容には偏りがあります.全ての分野に当てはまるとは言えません.よろしくお願いします.
研究とソフトウェア
コンピュータサイエンスの多くの研究では,規模の大小こそあれど,ソフトウェア(ないしスクリプト)を書いて実験を回すことになります.その過程でできたものをGitHub等で広く公開することも,最近では見られるようになってきました.論文に掲載された理論と実際の実装があれば,それを拡張することも,検証をおこなうことも容易になり,大変便利でありがたいです.しかし,そうして公開されるソフトウェアの多くは様々な要因が重なり,はっきり言うと使い物にならないことが多いです.
色々とその原因はあるのでしょうが,僕個人は,研究における開発は研究者当人の環境で動けば問題ないことが多く,他環境での再現性には注意が払われないという事態にしばしば陥りがちであるためと考えています.これは以下の様な事態を引き起こします.
- それを動かすための依存関係の情報が欠落している
- 使用方法が書いておらず,入力するデータをどのような形式で用意すれば良いのかわからない.
- ライセンスの表記がない
特に「依存情報の欠落」と「ライセンスの欠落」は致命的であり,このようなリポジトリは基本的に使用不可能に近くなってしまいます.卒業研究のような短期的に誰かが研究を行い,その後続の研究を誰か他の人が行うような事例の場合でもこれらの問題は顕在化し,しばしば技術/研究の継承を途切れさせてしまいます.
今回はこれらについて,最近使用されることが多くなってきたPythonにフォーカスし,いくつかの対処法を紹介していこうと思います.
依存関係の管理
どうして依存関係管理が必要なのか
使用するライブラリだけでなく,Python自体も,定期的な機能更新が行われています.しかし,テキストで記述されているソースコードから,使用されているライブラリ・Pythonのバージョンを推測することは容易ではなく,適していないバージョンのものを用いると,実行時にエラーが発生したり,予期しない結果になる恐れもあります.
また,使用されているライブラリはスクリプトを解析すれば分かるかも知れませんが,OS側にインストールが必要なものがあるとか,特定のハードウェアが必要であるとか,そういった情報も,開発した当人にとっては当たり前かも知れませんが,利用者にとってはそうではありません.これが依存関係の適切な管理・および把握が必要な理由です.
なぜAnacondaは微妙なのか
研究開発において,よくAnacondaが使用されています.
はっきり言うとAnacondaは必要な依存関係を隠蔽し,開発環境をガラパゴス化させる大きな要因の一つであると考えています.
Anacondaには,最初からビルド済みのデータ解析用パッケージが多数含まれており,パッケージのインストールのような特別な操作をわざわざしなくても最初から様々なパッケージの恩恵を受けることが出来ます.特にIntel MKLにリンク済みのnumpyなど,通常のインストールでは面倒なものを簡単にインストールできるため,大変人気です.しかし一方で,
- どのパッケージを自分は実際に使っているのか
- そのパッケージのどのバージョンを利用しているのか
といった情報からユーザを隔離してしまいがちです.仮想環境を作って運用していたとしても,その状態は明示的に残さない限りリポジトリには含まれないため,気をつけて運用する必要があります.
深層学習・機械学習は進歩がめざましく,パッケージの更新も頻繁にあるため,以前のAPIが使用不能になることは多く見られます.特に直近ではTensorflowが2.0への移行を進めており,将来的にデフォルトのバージョン*1が切り替わる事になります.ある実装がどのバージョンに対応しているのか,という情報が必要不可欠であることがわかります.
対処法1:Minicondaと仮想環境を使う
Windowsユーザは実質的にこれを選ぶしかありません.MinicondaはAnacondaの軽量版であり,自分でパッケージを選択してインストールする必要があります.
まずは1つの研究プロジェクト,ないしソフトウェアリポジトリごとに1つの仮想環境を作成してください.これにより,研究ごとのPython環境が隔離されるため,異なるプロジェクト間で異なるバージョンのパッケージを要求されても対応できるようになったり,どのパッケージが必要となっているのかが明白になったりします.
condaコマンドを使って仮想環境を作成できます.
# 仮想環境の作成 $ conda create -n 仮想環境名 "python==使うバージョン" $ conda install -n 仮想環境名 numpy # 環境へ入る $ conda activate 仮想環境名 # 環境から抜ける $ conda deactivate
このように作成した仮想環境の情報を明示的に残すためにはconda env export
というコマンドを使用できます.
# env.ymlとして環境の情報を出力する $ conda env export -n 仮想環境名 -f env.yml
こうして出力されたenv.yml
には以下の様なフォーマットでパッケージが記録されています.
name: 仮想環境名 channels: - defaults dependencies: - パッケージ名=バージョン=ビルド番号 - pip: - パッケージ名==バージョン prefix: /path/to/仮想環境名
このファイルを共有しておけば,OS,アーキテクチャを揃えれば他の環境でもconda env create -f env.yml
で同等の環境を復元することが出来ます.ただし,新しいパッケージをインストールしても自動的には反映されないため,変更したら再びexport
する必要があります.
対処法2:pipenvで自動的に管理する
Pipenvはrequestsなどの有名パッケージの作者であるKenneth Reitz氏による,新しい依存関係管理ツールです.pipと似たインターフェースを備え,Pipfile
およびPipfile.lock
により依存関係のバージョンを固定しています.
# pipenvのインストール $ pip install --user pipenv # 仮想環境の作成.PipfileおよびPipfile.lockが作成される # 明示的に使用するPythonを指定する場合 # pipenv install --python /path/to/python # または # pipenv install --python バージョン # ただし,pyenv等でこれらのバージョンが使用可能になっている必要がある $ pipenv install # パッケージのインストール $ pipenv install numpy # 仮想環境に入ることなく,仮想環境内のコマンドを呼ぶ $ pipenv run python main.py # 仮想環境に入る $ pipenv shell
今後はpipenv install
やuninstall
を行うごとにPipfileおよびPipfile.lockが更新されるため,これらをリポジトリに含めておけば良いです.Anaconda/Minicondaと違い,pipと同じパッケージを参照するため,MKL等は自分で導入する必要があります.
詳細な使い方は以下の参考リンクをご覧ください.
対処法3:setup.pyを書く
これは上記対処法1・2と共存できます.完璧にバージョンを指定するのではなく緩いバージョン制約を設けること,そしてそのパッケージをその仮想環境へインストールする事が出来るようになります.
まずプロジェクトのディレクトリ構造を以下の様にします.今回作るプロジェクトで使用するPythonモジュール群をpackage_a
ディレクトリ以下に置くものとします.
. ├── LICENSE ├── README.md ├── setup.cfg ├── setup.py └── package_a ├── __init__.py └── hoge.py
setup.pyを書きます.以下の内容だけで良いです.
from setuptools import setup setup()
setup.cfgを書きます.
[metadata] name = パッケージ名 version = バージョン # バージョンをPythonスクリプト内の変数から取ることも出来る # package_aの__init__.pyに`version = "1.0.0"`などと宣言しておけば以下で参照できる # version = attr: package_a.version author = 著作者 author_email = 著作者の連絡先 description = 説明 url = https://github.com/yourname/yourrepo # ライセンスファイルへのパスを指定 license_file = LICENSE [options] # Pythonバージョンの制約.以下だと3.5以上4.0未満 pythonrequire = >=3.5,4.0> # 含めるパッケージの選択.この場合は自動で探索 packages = find: # 列挙する場合は普通にインストールするパッケージを羅列すれば良い # ただしトップレベルパッケージのみ書いてもそれ以下のサブパッケージは含まれない # packages = # package_a # 依存関係の列挙 install_requires = # 以下なら1.0以上,2.0未満のhogeを要求する hoge>=1.0,<2.0 fuga [options.packages.find] # 自動探索から外すものを列挙 exclude = tests piyo
こうしておけば,setup.pyと同じ階層でpip install -e .
(pipenvの場合はpipenv install -e .
)でEditableモードとしてインストールできます.package_a
からのパスでのimportができ,コードを編集すればそれがそのまま反映されるため,何度もインストールする必要がありません.
# インポートする from package_a import hoge hoge.~~~
対処法4:Dockerイメージ化する
最近ではDockerが使用されることも多いです.この場合,OSレベルから依存関係を構築出来るため,より高い再現性を得られます.また,Dockerイメージを直接配布できるため,他環境で何度も環境を作るといった手間を省けるというメリットもあります.一方で,Linuxのコンテナ技術を利用するため,そのほかのプラットフォーム特有の機能を利用していたり,特定ハードウェアにロックインされている場合,GUIが必須の場合は注意してください.
CUDAを利用する場合はnvidia/cuda
のイメージを使うと良いです.下記の様なDockerfileと呼ばれるフォーマットのファイルを記述します.
FROM nvidia/cuda:10.0-cudnn7-devel-ubuntu18.04 RUN apt-get update -y && \ apt-get install \ python3 \ python3-pip RUN pip install \ tensorflow==1.14 \ numpy==1.16 COPY . /opt/hoge CMD ["python3", "/opt/hoge/main.py"]
ピュアなPythonイメージ(FROM python:バージョン
)を利用することもできます.CUDAが不要な場合はその方がイメージサイズが小さく,オススメです.Debianベースなので同じようにapt-getが使えます.
これも詳しくは参考リンクをご覧ください
Dockerアンチパターン
やってほしくない例です.
バージョン指定していないイメージ
FROM python RUN pip install tensorflow
このようなものはビルドごとに最新のものを使ってしまうため,異なるイメージが作成されてしまいます.バージョンはしっかりと指定してほしいです.
FROM python:3.6 RUN pip install tensorflow==1.14
なんでもイメージ
あらゆるライブラリ全部網羅!これさえあればOK!みたいなイメージは,結局のところ無駄にリソースを消費し,依存関係をややこしくするだけです.
- 初心者がとっかかりに使う
- Kaggleなどで汎用的に使える環境のために使う
のは良いかも知れませんが,再現性のための環境の配布でこういったことを行うのは明らかに悪手です.Web上ではよく見かけますが,こうしたイメージを使うならDockerでなくてもいいじゃんという気持ちです.
データ自体が入ったイメージ
大容量データセットをイメージ自体に含めるのは最悪なのでやめてください.イメージをローカルに展開しただけでシステムの容量を一気に持って行かれるのは大変困ります.
Dockerにはホストのディレクトリをマウントする機能があるため,データセットとイメージの配布は別々に行うべきです.
# カレントディレクトリのdatasetディレクトリをコンテナの/datasetにマウントして起動する $ docker run -v $PWD/dataset:/dataset hoge python ~~
docker commit
して作ったイメージ
dockerには,起動したコンテナ内での作業を永続化してイメージを作成するためのcommitという機能があります.いくつかのWebサイトには
- dockerコンテナを起動
- 何か作業
- git commit代わりにdocker commit
- Dockerhubへpush
みたいな例を見かけますが,いたずらにイメージの肥大化を招き,再現性のある環境を得ることが難しくなるだけなので辞めてください.
Dockerfileは再現性を得るためにわざわざビルド時に実行する処理を記述しているのであって,これを無視して実行結果だけを保存していくだけでは,目的を達成できません.
対処法5:READMEに書く
結局上記のどの対処法を使っても,これが必要になるという話ではあります.詳しくは次節に書きます.
その他の依存関係
対処法1~3では,OSにインストールする必要のあるライブラリについては一部を除きサポートできません*2.READMEなどに記述しておくべきでしょう.Dockerではこれらもまとめて管理できるため,出来るならDockerfileを用意することをオススメします.
使い方を残す
せっかく公開されていて動かすこともできるのに,どのように使用して良いか分からない!みたいな事例もあります.わかりやすい使い方が載っているかどうかだけでも,そのリポジトリが活用される可能性は大きく向上すると思います.
対処法1:READMEを書く
一番単純な方法ですが,意外とやらない人は多く居るという気がしています.書くのが面倒,情報を更新していくのが面倒,など事情は理解出来ますが,後々の自分のためにもある程度書いておいた方が良いと思います.
- 書いておいて欲しいこと
- 概要:このソフトウェアを使って何を達成できるのか
- 環境:どのOS・ライブラリを使うのか,その構築方法
- 使い方:どういう風に使うのか
- 設定:どういう設定項目があるのか
- ライセンス
- 引用のためのbibtexフォーマットのテキスト
- 書いていなくても良いなと思うこと
- 連絡先(何かあればissueに書けば良い)
- Known issue(issueに書いておけば良い)
特に,ユーザが知りたいのは
- 何を入力して
- 何が得られるのか
という情報です.この2点がしっかり分かるだけでも,そのリポジトリに対する評価は大きく変わってくると思います.
対処法2:コマンドラインオプションを作り込む
python main.py -h
などでヘルプメッセージを表示できるようにする,という意味です.これをしっかりと書いておけばそれ自体がドキュメントとなるため,その出力をREADMEに貼るだけでマシになります.
Pythonではargparse
というモジュールによって実装されています.簡単な使い方は下記で紹介されています.
より複雑なコマンドを作成する場合は拙作のCLIフレームワークもご検討ください.
対処法3:exampleを作っておく
どういうデータを用意すれば良いのか,その形式はどのようにすれば良いのか,などを簡単なサンプルを使って説明できるとより良いと思います.が,正直面倒だと思うので,ライブラリとして開発した上で,それを使用する実験スクリプトを全てexampleに突っ込むという構成がオススメかなと思っています.
$ tree -L 3 . ├── LICENSE ├── README.md ├── package_a │ ├── __init__.py │ └── hoge.py └── examples └── ex1 ├── __init__.py └── main.py
実際の実験スクリプトを分離しつつ,使用例を示せるので楽です.ただし,あくまでこれはオプションであり,exampleだから分かりやすくしないと!と必死になっては時間が溶けるだけなので注意しましょう.
また,実験の再現性に重点を置いて,論文中の図表と実行されるスクリプトとを対応付けるとよりわかりやすいかも知れません.他にも,どの順で何を実行するかを示したシェルスクリプトなどがあると,どの順でコードを追いかけていけば良いかも分かってくるため,実験実施中に使用したスクリプトを併記するのも良いかも知れません.
ライセンスを明記する
ライセンスが無いとどうなる?
GitHubの規約では,明示的にライセンスが示されていないリポジトリの扱いは以下の様になっています*3.
You're under no obligation to choose a license. However, without a license, the default copyright laws apply, meaning that you retain all rights to your source code and no one may reproduce, distribute, or create derivative works from your work.
つまり,ライセンスを一切選択しない場合,
ということです.当然,このような状態のリポジトリを第三者が扱うことは限り無く難しくなってしまい,公開されていて見れるのに使えない,という状況に陥ってしまいます.
OSSライセンスの種類
大雑把に分けてコピーレフトかそうでないか,という2種類があります.代表的な物をいくつかあげます.
- コピーレフトライセンス
- GNU General Public License v3(GPLv3)およびv2(GPLv2)
- クリエイティブ・コモンズのうち継承を含む物
- CC BY-SA
- CC BY-NC-SA
- そうでないもの
利用者に対して「このコードを組み込んで作ったりこれ自体を改変したソフトウェアは同じく公開してください」という通知をするのが概ねコピーレフトライセンスの概要であり,そういったものを要求せず.著作者の表示のみなど軽い条件を求めるのがそれ以外のものです.詳しいことは各ライセンスについて調べてみてください.
難しいことを考えたくない,いくらでも使ってくれ,というならMITやApache 2.0を採用すれば良いのでは無いかと思います.
ライセンスってどうやって書けば良いのか分からない
全てのファイルの先頭にコメントでライセンスを埋め込むことも出来ますが,より簡潔にするならリポジトリのルートにLICCENSEファイルを置くと良いです*4.
詳細は以下のhelpをご覧ください.
まとめ
OSS開発になじみのある人ならば,この辺りのことはほとんど呼吸のように行っている可能性がありますが,研究と開発は違います.その辺りは理解しているつもりですが,あまりにも使えないリポジトリと遭遇するので……
上記の内容が守られていれば,より利用されやすくなり,引用も増えて嬉しいのではないでしょうか.よろしくお願いします.
Pythonの新しいCLIアプリケーションフレームワークuroborosを公開した
はじめに
Pythonの全てのCLIアプリケーションフレームワークに習熟してるわけではないです.
自分が必要だと思ったものから優先的に実装しています.こうした方がいいとかあれば,リポジトリのIssueにお願いします.
背景
2019年現在,ソフトウェア系の研究をする人が避けて通れない言語がPythonと言っても過言では無くなってきました(炎上).実験でスクリプトを回すとき,パラメータ変更のために毎回ソースコードを書き換えるなんていう真似をしている人はおそらく居ないと思いますが,皆様どのようにCLIアプリケーションを構築されていますでしょうか.
Pythonの有名なCLIアプリケーションフレームワークはいくつかあります.僕の個人的な感想を併記します.
- Click
- ○:関数を簡単にコマンドにできるのは便利
- ×:デコレータ地獄になっているコードを読み解きたいという気持ちには全くならない
- Cliff
- ○:OpenStackのサポートがあって将来的なサポートも期待できそう
- ×:setuptoolsの力を借りないとサブコマンドを使えなくて嬉しくない
- Python Fire
- ○:Googleのサポートがあるので将来的なサポートも期待できそう
- ×:これ使いやすいですか?
- Cement
- ×:本家ドキュメントのGetting startedを読んでこんなに使い方が分からないとは思わなかった
- Plac
- ×:もはやPythonを書いていない
正直どれもこれも学習コストが高いか,可読性を犠牲にしており,それなら自分でargparse
のラッパーを書いた方がええわ!となりました.世間のPythonistaたちはどうしてるんでしょうか…
そもそもPythonのargparse
は非常に高機能で,CLIアプリケーション構築に必要な機能はほとんど網羅しているかと思います.インタラクティブシェル的な流行りの機能は難しいですが,そんな要件,普通に存在しますか?僕は幸い出会ったことがありません.というわけで,僕自身の機能に対するニーズはargparse
で十分に満たされており,後はどれだけ快適に書けるか,というところだけです.長くなりましたがこういう経緯で新しく実装することにしました.
方針
- 学習コストをできるだけ低く抑えること
- argparseの使用感を損なわずにコマンドを構造的に書けるようにすること
- 標準的な機能を利用する上では追加の依存を必要としないこと
- Python3.5以上のみをサポートすること
- もうこの世にPython2を使っているのはgcloudコマンドしか居ないため
気持ちだけGoのCLIアプリフレームワークのspf13/cobraを参考にしました.
uroboros
GitHubで公開しています.現在v0.1.0です.
名前の由来
ヘビっぽい単語で使えそうなのを探していたとき,ouroboros
(ウロボロス)は使われていましたがWikipediaを見るとuroboros
でも良さそうだったのでこれにしました.
ちなみにウロボロスは自分の尾を飲み込む蛇で終わり始まりが無いこと,不老不死,循環性,無限性の象徴ですが,このフレームワークにおいてサブコマンドは再帰的に構築され,ループしているとエラーを吐くので全然名前を表していないなと作ってから思いました.
インストール
pipでインストールするだけです.今のところサードパーティーの依存パッケージはありません.
$ pip install uroboros
使い方
覚える必要があるのはargparse
の使い方と,uroboros.Command
,uroboros.Option
だけです.しかも大抵の要件ではuroboros.Command
だけでも十分でしょう.uroborosではuroboros.Command
を継承して作成したコマンドクラスをノードとするN分木を作るようなイメージでCLIツールを構築していきます.
# main.py from uroboros import Command from uroboros import ExitStatus class RootCommand(Command): """アプリケーションのルートコマンド""" # アプリケーションのルートコマンド. name = 'sample' # アプリケーションの説明 long_description = 'This is a sample command using uroboros' version = "v0.0.0" def build_option(self, parser): """ 引数の追加. argparse.ArgumentParserのインスタンスが引数として渡される. """ parser.add_argument('--version', action='store_true', default=False, help='Print version') # 追加した後にparserを返す return parser def run(self, args): """ このコマンドが指定されたときに実行する内容. argsはargparse.Namespaceオブジェクトで引数をパースした結果. """ if args.version: print("{name} v{version}".format( name=self.name, version=self.version)) else: # このコマンドのヘルプテキストを出力するヘルパー関数 self.print_help() # 返り値はExit Statusになる. # `uroboros.ExitStatus`を使っても良いし,単にintでも良い. return ExitStatus.SUCCESS root = RootCommand() if __name__ == "__main__": # 実行時は単にそのコマンドのexecuteを呼ぶだけ exit_code = root.execute() exit(exit_code)
これが基本的なコマンド一つの実装になります.ポイントは
argparse.ArgumentParser
のインスタンスが渡されるので自由にオプションを追加する- 実行時には引数が
argparse
によってパースされ,argparse.Namespace
のインスタンスが渡されるので,自由にオプションを読み取って実行する - 返り値はそのまま終了ステータスになるので,intまたは
uroboros.ExitStatus
*1を返す
です.試しにヘルプを表示するとこうなります.
$ python main.py -h usage: sample [-h] [--version] This is a sample command using uroboros optional arguments: -h, --help show this help message and exit --version Print version # ちゃんとバージョン表示できる $ python main.py --version sample v0.0.0
ではサブコマンドを追加してみます.
# main.py from uroboros import Command from uroboros import ExitStatus class RootCommand(Command): ... class HelloCommand(Command): # サブコマンド名 name = 'hello' # サブコマンド一覧を表示したときの短いメッセージ short_description = 'Hello world!' long_description = 'Print "Hello world!" to stdout' def run(self, args): print(self.short_description) return ExitStatus.SUCCESS root = RootCommand() root.add_command(HelloCommand()) ...
これでhello
サブコマンドが使えるようになります.
# short descriptionはここで表示される $ python main.py -h usage: sample [-h] [--version] {hello} ... This is a sample command using uroboros optional arguments: -h, --help show this help message and exit --version Print version Sub commands: {hello} hello Hello world! # long descriptionはこっちで表示される $ python main.py hello -h usage: sample hello [-h] Print "Hello world!" to stdout optional arguments: -h, --help show this help message and exit # Hello worldしてみる $ python main.py hello Hello world!
更に複数のモジュールから複雑なコマンドを生成するサンプルはこちらにあります. これをargparseで実装する場合,(色々と省略すると)以下の様になります.
import argparse def print_version(parser, args): if args.version: print("sample v0.0.0") else: parser.print_help() def hello(parser, args): print("Hello world!") def main(): parser = argparse.ArgumentParser() parser.add_argument('--version', action='store_true', default=False, help='Print version') parser.set_defaults(func=print_version) sub_parser = parser.add_subparsers() hello_parser = sub_parser.add_parser('hello') hello_parser.set_defaults(func=hello) args = parser.parse_args() args.func(parser, args) if __name__ == '__main__': main()
細かい動作が違いますが概ねこういう感じです.規模が大きくなってきたときにどうなるかは考えるまでも無いでしょう.更にサブコマンドの下にサブコマンドを…等をし始めると,あっという間にスパゲティコードの誕生です.
uroborosでは内部でadd_subparser()
を使っており,実際の挙動としては上記のような挙動を全てラップしているような感じになります.
オプション引数の共有
いくつかのサブコマンドで同じオプション引数を使い回したいという需要はあると考えています*2.これを容易に実現する仕組みがuroboros.Option
です.コードの全体像はリポジトリのexampleに任せ,要点だけ説明します.このexampleでは指定されたディレクトリ内のファイルを一覧表示するfiles
コマンド, ディレクトリを一覧表示するdirs
コマンドを実装しています.
まずuroboros.Option
を継承したオプションクラスを作成します. uroboros.Command
と同様にbuild_option
メソッドで引数を追加できます.
from pathlib import Path from uroboros import Option, Command class CommonOption(Option): def build_option(self, parser): # 共通するオプションを追加する parser.add_argument('path', type=Path, help="Path to show") parser.add_argument('-a', '--absolute', default=False, action='store_true', help='Show absolute path') return parser class RootCommand(Command): ... # 共通するオプションをクラス変数`options`に設定する class DirsCommand(Command): name = 'dirs' options = [CommonOption()] ... class FilesCommand(Command): name = 'files' options = [CommonOption()] ... root = RootCommand() root.add_command(DirsCommand()) root.add_command(FilesCommand()) ...
これだけでdirs
サブコマンドとfiles
サブコマンドでpath
という位置引数と--absolute
というオプション引数が使えるようになります.
このOptionの良いところは単にくくりだして記述量を減らせるだけでなく,値のバリデーションをまとめることが出来る点にあります.
... class CommonOption(Option): def build_option(self, parser): ... # 実行時にCommandの`run`より先に呼ばれる def validate(self, args): # 返すのはExceptionのリスト.バリデーション違反がない場合,空のリストを返す. errors = [] # 指定したパスが存在しない場合エラーにする if not args.path.exists(): errors.append(Exception("'{}' does not exists.".format(args.path))) return errors ...
これで例えば存在しないパスを指定すると,files
サブコマンドでもdirs
サブコマンドでも共通して存在しないパスを弾くことが出来ます.
$ python main.py files /does/not/exists '/does/not/exists' does not exists. $ python main.py dirs /does/not/exists '/does/not/exists' does not exists.
注意点
良い意味でも悪い意味でのargparseのラッパーに過ぎないため,コマンドライン引数のパースは完全にargparse任せになっています.このため,現状ではサブコマンド以下の引数の名前と,親コマンドで使用している引数の名前がコンフリクトすると最後に設定したオプションで上書きされてしまいます.例えば
$ python main.py root -d fuga command1 -d poyo
のような仕様にした場合,最終的には後者の-d poyo
で上書きされてしまいます.これは
- 親コマンドの引数のパースをする
- サブコマンド以下の引数だけ抽出
- サブコマンドの引数のパースをする
の順で解決することでうまく行くはずですが,引数へのアクセシビリティが下がるため避けています.
つまり,今はargs.hoge
やargs.fuga
でアクセスできるコマンドライン変数に対しサブコマンドごとに名前空間を区切ると,args.subcommand.hoge
みたいなアクセスの仕方になってしまい,親コマンドからの相対的な位置に依存することになり,せっかく全てのコマンドが個別でexecute()
できる仕様が崩壊してしまいます.現状のコマンドの引数のみにフォーカスして渡すことも出来ますが,上位コマンドのオプション引数を解決できなくなってしまいます.
これについては今後の展望で述べるHook機能を使うことで一部解消できるはずです.各コマンドのオプションは各コマンドごとにパースし,必要な処理はHookで行うことで,最終的に実行されるCommandのrun
メソッドでは常にグローバルな名前空間にアクセスする必要がなくなる(親コマンドのオプション引数はその親コマンドのHookで解消する)ためです.が,逆に上位コマンドのオプションにはアクセスできなくなるため,上手い仕組みが必要だと考えています.
今後の展望
- 各コマンドにHookを用意する
- 例えばルートコマンドにHookを仕掛けてアプリケーション全体でのloggerの設定をするなどに使う
- バリデーションエラーハンドラーのサポート
- 現状ではエラーが発生したらそのままlogger.error()して終了してしまう.
- バリデーションからの回復を可能にするなどがあると便利そう.
add_command
で複数のCommandインスタンスを受け取れるようにする- すぐできるが需要があるのか分からない
- オプションをファイルから読み取り/ファイルへ保存
他にも要望や改善等あれば是非お願いします.
まとめ
argparseについての知識を活かしたまま,よりCLIアプリケーションを構築しやすくするためのフレームワークとしてuroborosを作成・公開しました.
これにより,サブコマンドの数の増加・そのネスト数の増加に伴って複雑化しがちなCLIアプリケーションを比較的簡単に構築することができるようになりました.
何かフィードバック等あれば遠慮無く頂けると幸いです.よろしくお願いします.