Python pexを使うべき場面と避けるべき場面

pexとは何か

pexは「Python Executable」の略で、Pythonアプリケーションとその依存ライブラリをひとつの実行可能ファイル（.pex）にまとめるツールだ。virtualenvに似た仮想環境の仕組みをファイル単体に封じ込めることで、配布先でpipやライブラリのセットアップをしなくてもPythonコードを動かせるようになる。

公式ドキュメントは pex.readthedocs.io にある。

pexが有効な場面

最も恩恵を受けるのは、依存関係のセットアップが難しい環境へPythonツールを配布するときだ。たとえば顧客の本番サーバにPythonは入っているものの、pipが使えない・社内ネットワークでPyPIに繋がらない・OSパッケージ管理が厳しく制限されているといった状況がこれにあたる。.pexファイルをコピーして実行するだけで動くため、環境構築の手順書を省ける。

CI/CDパイプラインでビルド成果物を一元管理したい場合にも向いている。バージョンごとにファイルをアーカイブしておけば、再現性の高いデプロイが実現しやすい。

# 例: requestsを含む単一実行ファイルを作成する
pex requests -c python -o myapp.pex

pexを使わない方がいい場面

WebアプリケーションをNginxやuwsgiと組み合わせて動かす構成では、pexのメリットはほとんどない。 フロントエンドのWebサーバやアプリケーションサーバが別途必要になる時点で、環境セットアップの複雑さはpex導入の有無にかかわらずあまり変わらない。Dockerコンテナで依存関係ごとイメージに固めてしまう方が、ログ管理・スケーリング・デプロイ自動化のエコシステムとの親和性が高い。

また、ライブラリがC拡張（.so/.dll）を含む場合は注意が必要だ。ビルドしたマシンのアーキテクチャや共有ライブラリのバージョンが配布先と異なると、実行時にエラーが出ることがある。この点はDockerイメージと同様の問題だが、pexはOSレベルの差異を吸収しないため、完全にポータブルとは言えない。

Dockerとの使い分け

pexとDockerは競合ではなく用途が異なる。Dockerはファイルシステム・OS依存ライブラリごと隔離できる反面、コンテナランタイムの導入が前提になる。pexはPythonランタイムさえあれば動くが、OS層の違いは吸収できない。

導入時に確認すること

pexを採用する前に、配布先のPythonバージョンがビルド環境と一致しているかを確認する。.pexファイルはビルド時のPythonバージョンに依存しており、異なるバージョンで動かそうとすると起動時にエラーになる。--pythonオプションでインタープリタを明示的に指定しておくと、この問題を事前に防ぎやすい。

依存ライブラリが多くファイルサイズが大きくなる場合は、配布手段（scp・S3・社内リポジトリ）も合わせて検討する必要がある。