モジュールの動的ロード

原文：http://python-history.blogspot.com/2009/03/dynamically-loaded-modules.html
原文投稿者：Guido van Rossum

Pythonの実装アーキテクチャは、開発の当初からC言語で書く拡張モジュールが作成しやすいような仕様になっている。しかし、初期の頃には動的なロードを行う技術がまだ明確になっていなかったため、このような拡張機能は、ビルド時にPythonと静的にリンクをする必要があった。これを行うために、C言語の拡張モジュールにはPythonと自分の拡張モジュールをビルドするMakefileを出力するシェルスクリプトが添付する必要があった。

この方法は小さなプロジェクトではうまく回すことができたが、Pythonコミュニティでは、予想を上回るペースで次々と新しい拡張モジュールが開発され始めていたため、コンパイルとロードを分離することができるような拡張モジュールへの期待が高まっていた。その後すぐにプラットフォーム固有の動的リンクAPIをラップしたインタフェースのコードが寄贈されて、".py"ファイルと同じようにimport文が外のディスクにある共有ライブラリを探しに行けるようになった。初めて動的ロードのことがCVSのログに登場したのは1992年の1月であり、1994年の末までにはほとんどすべての主要なプラットフォームがサポートされた。

動的なリンクのサポートはとても役に立つことが分かったが、それと同時にメンテナンスの悪夢に悩まされることになった。プラットフォームごとに異なるAPIを使用しており、何かしらの制約があるプラットフォームも存在した。1995年の1月には、動的リンクのサポートのコードは再構築され、すべての関連するコードは一つのソースファイルに集約された。しかし、結果として、プラットフォームごとの条件付きコンパイル指令(#ifdef)によって雑然とした大きなファイルが作られることになった。1999年の12月にはGreg Stein氏の協力を得て、プラットフォーム固有のコードはそれぞれのプラットフォームおよびプラットフォームのファミリーごとの固有のファイルに分割するという再構築を再度行った。

Pythonにおける動的ロード可能モジュールのサポートはこのように進展があったが、多くのユーザにとってはそのようなモジュールをビルドする手順というのは不可解なものとして残ってしまっていた。モジュールをビルドするユーザ数は大きく増えてきた。特に、SWIGのような拡張ビルドツールの導入もこれを後押しした。しかし、拡張モジュールを配布しようとするユーザは、プラットフォーム、コンパイラ、リンカのすべての考えられる組み合わせ上で、モジュールをコンパイルするという大きなハードルに直面した。最悪のケースのシナリオは、ユーザがそれぞれ、コンパイラとリンカに渡す正しい設定を書いたMakefileとコンフィグスクリプトを作成する必要があるというものである。あるいは、ユーザが自分の拡張モジュールの情報を、Python自身のMakefileに追加し、Pythonの部分再ビルドを行って、正しいオプションでモジュールのコンパイルを行う必要があった。しかし、この方法は、エンドユーザがPythonのソースファイルを手に入れなければならないのが問題である。

最終的には、distutilsと呼ばれるPython拡張のビルドツールが考案されて、どの環境でもPythonの拡張モジュールのビルドしてインストールできるようになった。Pythonのmakefileによって、必要なコンパイラとリンカのオプションはデータファイルに書き込まれるようになった。このファイルはdistutilsが拡張モジュールをビルドする際に参照される。distutilsのほとんどの部分はGreg Ward氏によって作成された。古いPythonのバージョンをサポートするためにdistutilsの最初のバージョンはPythonとは別に配布されたが、Python 1.6からは標準ライブラリのモジュールとしてPythonの配布物に統合された。

distutilsには他にも注目すべき点がある。ただC言語のソースコードから拡張モジュールをビルドするだけにとどまらず、様々なことができるようになっている。ピュアPythonのモジュールやパッケージのインストールにも使用することができるし、Windowsの実行可能なインストーラを作成したり、SWIGのようなサードパーティの作成したツールを実行することも可能である。しかし、多くの人は複雑で、メンテナンスをするのも苦労するようなdistutilsに悩むようになった。そのため、最近ではサードパーティによる代替策("eggs"の別名でも知られるez_install)も人気になりつつあるが、同様に、動かないという苦情が出たりして、開発コミュニティの分断を引き起こしてしまっている。この拡張モジュールのビルドを完全に一般化をするという課題は、本質的に難しい問題である。

※訳注：distutilsのメンテナンスの苦労という話が出ているが、ez_installが備えている、パッケージ名を指定してウェブサイトからダウンロードしてインストールしたり、関連するモジュールを一緒にインストールしたり、適切なバイナリパッケージを自動選択したり、アップデートを行ったり、といったパッケージマネージャ的機能がなく、ソースコードからのクリーンインストールしかできないことを言っていると思われる。