はじめに
こんにちは、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では特に気にする必要はありません。
もしこの辺のいきさつを知りたい場合は次のエントリを参照してください。(古い話なので、そこまで知りたい人でなければ特に気にしなくてよいです。)
ただし、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 -V Python 2.7.9
ちゃんとPython2系がデフォルトの環境でPython3.4の環境を作れていますね。
virtualenvwrapperについて
virtualenvwrapper
は virtualenv
での環境作成や環境の切り替えを便利にするためのラッパーツールなので、内側で何をやってるかわかれば、使う使わないは本人次第です。 virtualenvwrapper
でやっていることは次の内容だけです。
mkvirtualenv
では特定のディレクトリ以下(eg.$HOME/.virtualenvs
)でvirtualenv
のオプションをそのまま受け取って環境を作成するworkon
ではdeactivate
を実行し、指定した環境のbin/activate
を実行するrmvirtualenv
では、mkvirtualenv
で作成した仮想環境のディレクトリを削除する。
「ディレクトリの移動などが本当に面倒」という人であれば使えばよいと思います。
まとめ
巷にいろいろとツールがあり、それらを紹介するエントリーがたくさん見つかるので、何か複雑なように見えますが、その実はシンプルです。デファクトスタンダードを使って、それをみんなでよくしていこう、というPythonのエコシステムに乗っかるほうがいろいろと便利ですよ。