はじめに
こんにちは、Python界のテリー・ギリアムです。こんな記事を見かけて、Pythonの開発環境を作るのが面倒という認識が広まるのは良くないなあと思って書きました。ただの突っ込み記事です。
そのツールほんとに要りますか？
出だしにこんなセクションタイトルがありました。
その仮想環境本当に必要ですか？
たしかに仮想環境要らないひとは要らないよねっていうのは同意です。その場合、入ってるPythonのsite-packagesにどんどんパッケージがインストールされるだけなので、手動で消せる人はそれでいいし、そもそもパッケージのバージョンとか知るかって人はそのままパッケージインストールすればいいと思います。
とはいえ、複数のプロジェクトでパッケージのバージョンがぶつかったら困る人とかいるし、そういう人は仮想環境を使うことになるでしょう。で、件の記事ではいろいろなツールを紹介していますが、そもそもそんなにツール要りますか？というのが本記事の主旨です。
The Zen of Python
PythonにはThe Zen of Pythonという、Python自体の考え方や、それから派生したPythonで開発する上での指標となるものがあります。見たことがない人は次のコマンドで確認してください。
$ python3 Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 08:06:12) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
今回の話につながるところでいくと、次の3つがあります。
- Simple is better than complex. （シンプルなのは複雑であることよりも良い）
- There should be one– and preferably only one –obvious way to do it.（1つだけ、できれば唯一、の明らかな方法があれば良い）
- If the implementation is hard to explain, it’s a bad idea.（その実装の説明が難しいなら、そのアイデアは良くない）
ツールに関してもそうです。シンプルなものがあればそれを使おう、なるべくシンプルな構成にしよう、という考え方です。
virtualenv (venv)があればたいていのことは済む
pyenvを便利に使ってる人はいるんでしょう。しかし、pyenvのpython-buildは便利かもしれませんが、そんなに細かくPythonをインストールする必要がある人ってどれだけいるんでしたっけ？
pyenvはPythonのインストールから含めてオールインワンの実行環境を提供したいという目的があるのでしょうが、そもそもPythonのマイナーバージョンのアップデートはそこまで大きくなく、マイナーバージョンのリリースもかなり慎重です。実際マイナーバージョンでの下位互換性は高く、マイナーバージョンのアップデートも1年に1回程度です。公式のリリース情報のページで確認できます。
プロジェクトで稼働させているバージョンを固定させているならそのバージョンだけ入れればよいわけですし、マイナーバージョンごとにアップデートを行うにしても1年に1度あるかないか、さらに攻めた環境でマイクロバージョンごとにインストールするにしてもたかが知れています。（マイナーバージョンは大概がセキュリティフィックスか明らかなバグ修正。）であれば、pyenvでPythonを新規にインストールする必要ってどれくらいあるんでしょう。マイクロバージョンごとに確認しなければいけないライブラリ作者ぐらいでしょうけれど。
Pythonのインストール自体は configure、make、make installをするだけなので、かなり簡単にビルドできます。（pyenvでインストールを実行している内容もこれです。先ほどのThe Zen of Pythonでいえば “Explicit is better than implicit.” の項に当てはまる内容ではないでしょうか。）
で、本題の「どのツールが必要なの」という点ですが、基本的に virtualenv (venv) があれば事足ります。
venvのみを使う場合
venvはそもそもvirtualenvというツールがPython2系で広く使われてデファクトスタンダードになった時期がPythonのLanguage Moratoriumの期間に重なり、その時期にPython3ではこれを標準に入れようという動きから取り込まれたものです。
- PEP 3003 -- Python Language Moratorium | Python.org
- PEP 405 -- Python Virtual Environments | Python.org
ですので、基本的には同じものと考えてもらって問題ありません。またパッケージ管理ツールに関しても現状ではpipに落ち着き、後ろで使われるパッケージングもwheelで安定したので、この辺はpipがデフォルトでインストールされる最近のPythonでは特に気にする必要はありません。
- http://pythonwheels.com/
- PEP 427 -- The Wheel Binary Package Format 1.0 | Python.org
- PEP 453 -- Explicit bootstrapping of pip in Python installations | Python.org
もしこの辺のいきさつを知りたい場合は次のエントリを参照してください。（古い話なので、そこまで知りたい人でなければ特に気にしなくてよいです。）
ただし、venvはPython3以降でしか使えません。Python3以降のみで使う場合には venv で事足りる、という認識でよいと思います。たまに例外もありますが、その場合は virtualenv を使えばよいでしょう。（Debian系では venv に必要な ensure-pip が設定されてないバイナリがインストールされることがあるのでその場合は python3-pip を入れてpipで virtualenv だけ入れればよいです。）
venv が入っていれば次のコマンドで仮想環境を作成できます。
$ python3 -m venv hoge $ . hoge/bin/activate
virtualenvを使う場合
Python2系とPython3系両方でうまくやりたい場合は virtualenv を使えば良いです。基本的に venv は virtualenv の中からPython3系だけでうまくやるために必要なものだけ切り出してるので、基本的にできることは変わりませんし、メジャーバージョンを切り替えるような場合は virtualenv 一択となります。
virtualenvはPython本体のバージョン切替には使えませんし
先のエントリではPython本体のバージョン切り替えができないと書かれていますが、ふつうにPythonのバージョンの切り替えもできますよ。virtualenv のオプションを確認してみましょう。
-p PYTHON_EXE, --python=PYTHON_EXE
The Python interpreter to use, e.g.,
--python=python2.5 will use the python2.5 interpreter
to create the new environment. The default is the
python2 interpreter on your path (e.g.
/usr/bin/python2)
たとえば、Python2系がデフォルトの環境で、virtualenvでPython3系の環境を使いたいとき。
% python -V Python 2.7.9 % python3 -V Python 3.4.3 % virtualenv --version 1.11.6 % virtualenv -p python3.4 hoge Running virtualenv with interpreter /usr/bin/python3.4 Using base prefix '/usr' New python executable in hoge/bin/python3.4 Not overwriting existing python script hoge/bin/python (you must use hoge/bin/python3.4) Installing setuptools, pip...done. % which python /home/ymotongpoo/hoge/bin/python % python -V Python 3.4.3 % deactivate % python -V Python 2.7.9
ちゃんとPython2系がデフォルトの環境でPython3.4の環境を作れていますね。
virtualenvwrapperについて
virtualenvwrapper は virtualenv での環境作成や環境の切り替えを便利にするためのラッパーツールなので、内側で何をやってるかわかれば、使う使わないは本人次第です。 virtualenvwrapper でやっていることは次の内容だけです。
mkvirtualenvでは特定のディレクトリ以下（eg.$HOME/.virtualenvs）でvirtualenvのオプションをそのまま受け取って環境を作成するworkonではdeactivateを実行し、指定した環境のbin/activateを実行するrmvirtualenvでは、mkvirtualenvで作成した仮想環境のディレクトリを削除する。
「ディレクトリの移動などが本当に面倒」という人であれば使えばよいと思います。
まとめ
巷にいろいろとツールがあり、それらを紹介するエントリーがたくさん見つかるので、何か複雑なように見えますが、その実はシンプルです。デファクトスタンダードを使って、それをみんなでよくしていこう、というPythonのエコシステムに乗っかるほうがいろいろと便利ですよ。
2017.01.30 追記
- 「Linuxディストリビューション以外の方法でパッケージをインストールしたくない」
- それもありだとおもいます。新しいバージョンのPythonパッケージを利用する必要がないならそれで十分だと思います。余計なスタックを増やさないという点で優れていると思います。
- 「dockerで事足りている」
- dockerが自由に使える人はそれでまったく問題ないと思います。僕もテストなどはdocker環境でテストします。
- 「virtualenvwrapperを使ってもなおworkonなどを打たないと環境が切り替えられない。面倒だ。」
- であれば
direnvを使うのも一考かと思います。何れにせよそのためだけにpyenvを入れるのはスタックがでかすぎると思う。
- であれば
- 「pyenvのほうがPython2/3の切り替えが便利だ」
- 上の記事は読まれましたか？
- 「Pythonの環境構築方法で揉めてるんですか？」
- 揉めてませんよ
![お料理用 水温制御クッカー/サーキュレーター（スマホと連動して水の温度をコントロール） [並行輸入品]](http://d.hatena.ne.jp/images/hatena_aws.gif "お料理用 水温制御クッカー/サーキュレーター（スマホと連動して水の温度をコントロール） [並行輸入品]")
