YAMAGUCHI::weblog

噛み付き地蔵に憧れて、この神の世界にやってきました。マドンナみたいな男の子、コッペです。

Pythonの仮想環境構築 2017.01版

Python

はじめに

こんにちは、Python界のテリー・ギリアムです。こんな記事を見かけて、Pythonの開発環境を作るのが面倒という認識が広まるのは良くないなあと思って書きました。ただの突っ込み記事です。

qiita.com

そのツールほんとに要りますか？

出だしにこんなセクションタイトルがありました。

その仮想環境本当に必要ですか？

たしかに仮想環境要らないひとは要らないよねっていうのは同意です。その場合、入ってる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ではこれを標準に入れようという動きから取り込まれたものです。

ですので、基本的には同じものと考えてもらって問題ありません。またパッケージ管理ツールに関しても現状では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 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 追記

ブコメやTwitterでの反応を元にコメント。