wheelとは、ビルド済みパッケージのインターフェス/フォーマットである。
Specification
PEP 427 -- The Wheel Binary Package Format 1.0
This PEP describes a built-package format for Python called "wheel".
背景
ライブラリの導入にはbuildとinstallation、2つの段階がある。
例えばソースコード配布（sdist）の場合、ユーザーはビルドシステムの導入、パッケージダウンロード、パッケージビルド、パッケージインストールの段階を踏む。
この方法を取る場合、ビルドとインストールの密結合という欠点が生まれる。
インストーラーがダウンロードをおこなった後にビルトシステムがbuildし、またインストーラーがインストールを行うため、ビルトとインストールが密結合になっている。
これによりユーザーはビルトシステムとインストーラーの両方が必要になる。ビルトシステムとインストーラーが1つのシステムになっているため、個別の開発や個別のアップデートも困難になっている。
この解決方法はバイナリ配布（bdist）である。
ビルトシステムの導入とビルド、その後にビルド済みパッケージのダウンロードとインストールを行うことで、密結合が解消される。
ビルド済みパッケージを配布することで、ユーザー側はビルドシステムの導入およびビルドそのものが不要になる。
結果としてユーザーはダウンロードとインストールを責務に持つインストーラー/パッケージマネージャのみを持てばよくなる。
分離された2段階の間にインターフェス/フォーマットを定義できれば、ビルダーはビルダー側で改良ができ、インストーラーはインストーラー側で改良ができる。
例えばインストーラーの開発/更新が滞っていたとしても、パッケージ開発者は最新ビルダーを問題なく導入できる。
このインターフェス/フォーマットがwheel
Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. by PEP427
形式
- archive: zip
- extention: .whl
/
{distribution}-{version}.dist-info/
METADATA : package metadata (required)
WHEEL : wheel metadata(required)
RECORD : a list of (almost) all the files in the wheel and their secure hashes (required)
distribution}-{version}.data/
Questions
これ、multi-packageも可能な感じなのか？
仕様書読んでるとそんな感じした（/{distribution} ディレクトリを1つだけ持て、的な記述が一切ない）
