「ポータブルさ」を評価してPyPyを軽い業務用途で採用したケース

まえがき

Pythonの実行環境となる実装には、PSFが公開しているCPython以外にもいくつか存在します。 ¹

そんな実装系の一つであるPyPyをちょっとした理由で業務利用したので、ちょっとしたログがてら感想等をまとめてみます。

PyPyについての簡単な説明

Python処理系の実装の一つで、大雑把に説明すると「Pythonで書かれたPython」と言えます。

内部実装に起因する挙動の違いなどはありますが、言語としての動作に関しては極端な差はありません。
そのため、通常のCPython向けに書かれた.pyのソースはそのまま動作することも多いです。

特に速度面でCPythonの優位を取れるシーンがあり ²、競技プログラミング分野で目にすることが度々あります。 ³

PyPyの「ポータブルさ」

どこかに詳細な解説があると信じて相当量の説明を省くと、PyPyをインストールをするのに必要最低限となる作業はこれだけです。

1. PyPyのダウンロードページから、自分の環境にあったパッケージアーカイブをダウンロードする。
2. ダウンロードしたファイルを展開する。

以上です。PyPyのサポート環境であれば、これだけで実行準備が整います。

コマンド例

$ cd /path/to
$ curl -LO https://downloads.python.org/pypy/pypy3.10-v7.3.13-linux64.tar.bz2
$ tar xf pypy3.10-v7.3.13-linux64.tar.bz2
$ ./pypy3.10-v7.3.13-linux64/bin/python -V

え？普通のOSディストリビューションならオペレーションに大差ないのでは？
多くの場合はそうとも言えるのですが、そうでないポイントもあるので、そこを説明していきます。

古めのOSでも割りとすんなり動く

この「アーカイブをダウンロード・展開して完了！」が有効に働くポイントとして、見出しにもあるように古めのOSでも導入が容易という点が挙げられます。

比較的長く受託している案件で、基盤のOSがまだCentOS 7系なものがあるのです。ここに、ちょっとしたツールのために新しめのPython実行環境を必要としました。

というのも、Pythonを使うにしても、CentOS 7.xのBaseリポジトリにあるのは2.7.5と流石に古いためです。また、EPELなどを駆使しても案外手間で、最終的に「新しめのCPython」のためにはビルドが要求されてしまいます。

ダウンロードページにあるLinux向けリンクのNotesには、こう書かれています。

compatible with CentOS7 and later.

そう、CentOS 7系でも動作することが保証されているのです。

PyPyはPythonのバージョン仕様との互換性のために3種類の実装が提供されているのですが、新しいものはPython 3.10系互換となっています。
今のCPythonのリリースは3.12系が最新なので多少は遅れていますが、それでも困らない程度には追従できています。

venv以上に使い捨て/持ち運びがしやすい

現在のPythonにおける環境管理は、何かしらの形でvenvなどを利用した仮想環境を作成してそこにライブラリをインストールするのが一般的です。
当然ながら、不要になったりした場合は仮想環境を消すことで使い捨てをすることが出来ます。

一方PyPyの場合は実行環境をまるごと消して再ダウンロードすることが可能なので、よりダイナミックな使い捨てが実現できます。 ⁴

また、実行環境そのものがポータブルなので、次のようなことも視野に入れることが出来ます。

1. 環境設定向けの環境でPyPyへ依存ライブラリのインストール（venvは使わない）
2. インストール済みのライブラリごと圧縮
3. 再圧縮したファイルを実行したいマシンへ配布

デメリット周り

ポータブル性に着目すると前述の通り便利なポイントがそれなりにありますが、とはいえガッツリ使うには面倒な箇所も多々あります。

いくつかピックアップしてみます。

PATH管理しづらい...かもしれない

特にポータブル性を意識すると、PyPyを環境まるごとポコポコ作るケースも想定できるのですが、そうするとPATH周りをどうするかがちょっとした課題になります。
とはいえ、実行時の記述が若干冗長になるだけなので、ターミナル上での頻繁なコマンド入力をしないのであれば余り気にはなりません。

ライブラリインストールが手間になるケースがある

PyPIに登録されているライブラリは大きく分けて以下の2形態を取ります。（説明は超概要）

• Source: セットアップ情報とPythonソース等を含めた形式。インストール時にビルド等が発生する可能性がある。
• Wheel: プラットフォームごとに用意されたビルド済みファイルを梱包した形式。基本的にそのまま展開した状態で使える。

Pure-PythonなライブラリではSource形式しか提供されていないこともあり、実際に困ることは余りありません。

一方で困るのが、ビルドが必要なライブラリでWheelが提供されていないケースがあります。
Wheelはパッケージ作成時に「Pythonのバージョン」「OS」「CPUアーキテクチャ」などの要素で別ファイルとして用意する必要があります。
そのため、PyPy向けのWheelが存在しないケースが発生しがちです。⁵

この場合、どこかでビルドを含むインストールが必要になります。こうなってくると、実行環境として採用するのが少々面倒になります。

振り返り

というわけで、多少のデメリットは無視できる範囲において、PyPyを小さな範囲で利用していくのは案外メリットが有りそうです。
みなさんも、限定条件下では実案件でもチマチマ使ってみる機会を伺ってみると良いかもしれません。

1. 今回紹介しないものだと、JVM上で動作するJython、組み込み向けのMicroPythonなどがあります。 ↩

2. https://speed.pypy.org/ で、CPythonとの速度比較をしています。（ただし比較対象がかなり古め） ↩

3. 自分がたまに挑戦する際はPythonをメインで使っていますが、「わずかにTLEが出たからとりあえずPyPyに差し替えてみるか」という扱いをすることがあったりします。 ↩

4. 書いてはみたものの、そこまで強いメリットはないです。 ↩

5. 例としてあげると、NumPyにはPyPy向けのWheelも提供されているのに対して、CythonにはPyPy向けがリストにありません。 ↩