読者です 読者をやめる 読者になる 読者になる

Pythonの環境管理ツール良し悪し

本記事は社内向けに書いた文章を修正したものである。

世の中にある代表的な「Python環境管理ツール」に virtualenv, pyenv, venv の3つがある。これらをGoogleで検索すると使い方が書かれたページばかりが出てきて、それらの違いや使い分けを解説する記事は少ない。

本当は必要ではないのに「pyenvは便利」のような謳い文句で何となく使わせる記事や、古い情報を元に書いた「一見新しそうに見える記事」も多く見られる。

この記事では、中立・実用重視な視点から各ツールを解説し、筆者が考えうるベター（ベストは人それぞれ）な組み合わせについて書く。

なおAnacondaは初学者には推奨できない。Anacondaについての筆者の解釈は末尾にあるためそちらも参照されたい。

TL; DR

この文章で話すことをかんたんに言うと、

  • pyenvでPythonの複数バージョンを管理する
  • venvでパッケージ環境を切り分ける (Python 2ならvirtualenv)

以上の組み合わせがいろんな意味で柔軟かつサポートが安定している

用語

この記事では「バージョン」という言葉はPythonのバージョンを指し、同様に「バージョン管理」はPythonの複数バージョンをインストールしたり消したり切り替えたりすることを指す。

加えて「パッケージ環境」という言葉はパッケージが入ったディレクトリ一式、具体的にはsite-packagesなどPYTHONPATHで探索される対象一式を指す。同様に、「パッケージ環境管理」という言葉はこのパッケージの組み合わせを切り替えたり作ったり消したりすることを指す。

ツールの用途比較と解説

今回比較するツールは以下の通り。

  • virtualenv
  • venv
  • pyenv

以下については触れない。

  • Anaconda （本記事末尾を参照）
  • virtualenvwrapper （virtualenvの節を参照）
  • requirements.txtとかconstraints.txtとかpipfileとか「違う意味でのバージョン管理」

virtualenv

用途: パッケージ環境管理

長所

  • 人気かつ歴史が長い
  • PyPAによってサポートされている
  • 作った環境を読んで動作を変えてくれるエディタもある（PyCharmなど）

短所

  • バージョン指定なしでも実行できてしまうため、どのバージョンのPythonインタプリタで実行されるかわかりにくい
  • 環境内にインタプリタ本体がごっそり入るので容量を食う

解説

深刻な欠点もなく、十分にシンプルで挙動も理解しやすいツールだ。ただし virtualenv というコマンドを直接実行するとシステム標準のPythonと自分で入れたバージョンとがごっちゃになり事故が起きやすいので注意。

virtualenvwrapperなるツールを使えばどこからでもactivate/deactivateできるようになるが、virtualenvの動作を隠蔽しトラブルの種となりえるためこれもまた初学者には向かない。

なおvirtualenvの機能はPython 3.3から「venv」という名前で標準ライブラリに取り込まれた。後述の利点に加え標準に則る観点からPython 3を使う場合はvenvを使うとよい。

venv

用途: パッケージ環境管理

長所

  • Python標準ライブラリ
  • virtualenvとほぼ同じなため使いやすい
  • インタプリタをコピーせずリンクを貼るだけなので環境あたりのサイズが小さい
  • バージョン指定をしない古い呼び方 pyvenv で呼ぶとwarningを出してくれるため事故が起きにくい

短所

  • 使い方に関する情報が少し錯綜している
  • 実行コマンドが冗長

解説

virtualenvが標準ライブラリに取り込まれ進化したもの。ほぼvirtualenv互換でありながら標準ライブラリの手厚いサポートがあるため、venvが使えるバージョンでvirtualenvをわざわざ使う理由はない。これからはvenvが業界標準となるだろう。 環境のサイズの小ささが特徴で、実際の bin ディレクトリの大きさ比較をしたのが以下の画像である。上がvenv、下がvirtualenv。

f:id:puhitaku:20170403234336p:plain

実際に利用する際は python3.6 -m venv my_env のようにvenvモジュールを直に実行する。打つのが面倒だが、aliasを貼るなどすれば特に問題はない。

Python 2ではvenvは提供されないためvirtualenvを使い続けることになる。とはいえこれからPython 2のコードを書き起こすケースはめったにないのでさほど問題にはならないだろう。

pyenv

用途: バージョン管理 + パッケージ環境管理 (by virtualenv)

長所

  • shellで書かれていてPython自体に依存しない
  • pyenv install 3.6.1 のように打つだけで好きなバージョンがインストールでき、切り替えも容易
  • virtualenvへのバインディングを標準で搭載し、バージョンを切り替えるのと同じインターフェースでパッケージ環境も切り替えられる

短所

  • PATHの挙動やPython自体を理解しないうちに導入すると混乱の元となりやすい
  • virtualenvの管理もできるが、pyenvのテリトリーに置くためPyCharmが空気を読んでくれない (pyenvwrapperと似ている)

解説

virtualenv / venv はPythonのバージョンごとに入っているライブラリであり、Pythonのバージョンを切り替えるといったメタな管理は担当しない。pyenvはここを担当できるツールとなる。

バージョン管理とパッケージ環境管理を統一した便利さと引き換えに魔法が多く使われており、加えてvirtualenvとpyenvの立ち位置が理解しづらいためとにかくトラブルになりやすい。shellをある程度理解しこれから本気でコードを書く立場の人なら良いが、Pythonは道具に過ぎないデータサイエンティストなどライトな層には向かない。

筆者は根っからのpyenvユーザーだが、PyCharmとのインテグレーションもほぼ効かず手動指定しなければならないため、最近はvenvによるパッケージ環境管理に移行を検討している。

virtualenvの管理としてpyenvを使うのはおろかvirtualenv自体もvenvに取って代わろうとしているため、今後pyenv経由でパッケージ環境を管理するのは得策ではないだろう。

pyenvの最大の利点はPythonの複数バージョンを手軽に統一管理できる点だ。常に最新のPythonを入れるOSのパッケージ管理ソフトとは違い、パッチバージョン単位で好きに過去のバージョンをインストールでき、削除も簡単だ。この機能のためだけでもpyenvを導入する価値がある。

まとめ

ここまでの話をまとめると以下のようになる。

プログラマーの場合

Pythonが複数バージョンにまたがる際はpyenv (python-build)でインストールし、 pyenv global 2.7.10 3.5.2 3.6.1 のように使いたいバージョンをすべて有効化しておく。これでシステム標準のPythonを隠すことも達成できる。

パッケージ環境を分けたい際は python3.5 -m venv newenv のようにvenvで環境を作りactivate/deactivateする。PyCharmはこれを読んで自動で環境を切り替えてくれる。

なお id:orisano から「python-build単体でいんじゃね？」との提案があった。筆者の場合、いろんなバージョンを入れたり消したりするのが楽なのと、各バージョンの bin へのPATH通しが楽なためpyenvをそのまま使っている。もともとpyenvヘビーユーザーだからなのもあるが、ここは好みなので各自工夫するのがいいと思う。

それ以外の場合（データサイエンティスト等）

Pythonは常に2/3の最新が使えれば良いので、apt/yum/homebrew等で最新のPythonをインストールしておく。パッケージ環境を分けたい際はプログラマーと同じくvenvを使う。

参考: Anacondaについて

Anacondaは簡単に言うと「最初からNumpyやJupyter Notebookが入っていて、ビルド済みバイナリをインストールすることで利用者の環境構築が省け、ついでに複数バージョンのPythonを管理したり環境を切り替えることもできる一大ディストリビューション」である。

響きはとても便利なのだが、何かと弊社内でもトラブルの根源となっているので初学者には使わないでほしい。

Anacondaはそれひとつでエコシステムを形成しきってしまうものであり、最初からPythonが入っておらずビルド環境の準備が面倒なWindowsでは特に実用的である。しかしながらUNIX-like OSではビルド環境が要らない利点よりもシステム標準のPythonを遮蔽するなどの欠点が目立ちやすく、おまけにWebにあるAnaconda導入記事に低品質なものが多いせいで初学者がトラブルに陥るケースが少なくないのだ。

例えば、必要もないのにpyenvをインストールさせられてトラブルに陥り、結果pyenvやAnacondaの評判を落としかねない情報が拡散されるといった問題が取り沙汰されたのは記憶に新しい。

Anaconda開発元のContinuum Analyticsが書いたドキュメントでは公式インストーラーでの導入方法が丁寧に説明されているのだが、日本語での検索では日本語で解説している非公式の記事が優先的にヒットするため低品質な導入手順にぶちあたりやすい。

Pythonに慣れていない人でも踏み入れやすい素晴らしいディストリビューションながら、このように周囲のユーザーが複雑な・あるいは間違った情報を共有しているケースが大変多いのがAnacondaであり、初手でここから始めるのは強く避けるべきである。

参考