用語集#
- バイナリ配布物#
`ビルド済配布物 <Built Distribution>`の特定の種類で、コンパイル済みの拡張部分を含むもの。
- ビルドバックエンド#
ソースコードツリーを受け取って、そこから ソースコード配布物 や ビルド済配布物 をビルドするライブラリ。ビルドの作業は、 フロントエンド によってバックエンドに委任されます。
ビルドバックエンドの例としては、 flit の flit-core 、 hatchのhatchling 、 Maturin 、 meson-python 、 scikit-build-core 、 Setuptools があります。
- ビルドフロントエンド#
任意のソースコードツリーまたは ソースコード配布物 を入力として、それらからソースコード配布物または wheels をビルドするためにユーザが走らせるであろうツール。実際のビルド作業は、それぞれのソースコードツリーの ビルドバックエンド に委任されます。
- ビルド済配布物#
配布物 フォーマットは、インストールするためにターゲットとなるシステムの適切な位置に移動させることに必要となるファイルやメタデータだけを含んでいます。 Wheel はそのようなフォーマットですが、インストールできるようになる前にビルド段階が必須となると言う点で ソースコード配布物 はそうではありません。このフォーマットであることは、 Python のファイル群があらかじめコンパイルされた状態でなければならないということを意味しません (Wheel では意図的にコンパイル済みの Python ファイル群を含まないようになっています)。より詳しくは パッケージフォーマット を見てください。
- ビルドされたメタデータ#
インストールされた プロジェクト (
METADATAファイル) や 配布物アーカイブ (Sdist の中のPKG-INFOや Wheel 内のMETADATA) の内部に含まれる場合に コアとなるメタデータ が具体的な形式を取ることになります。- コアとなるメタデータ#
仕様 および コアとなるメタデータのフィールド <Core Metadata Fields において、 配布パッケージ あるいは インストール済みのプロジェクト の鍵となる静的なアトリビュートを記述するものを定義しています。
- コアとなるメタデータのフィールド#
コアとなるメタデータ の仕様の中で定義され、 ビルド済みのメタデータ の中に保存される、単一のキー・バリューペア (または、複数の使用方法のあるフィールドについては、一連の同名のキー・バリューペア)。特筆すべきことに、 Pyproject メタデータキー とは区別される。
- 配布物アーカイブ#
配布パッケージ のための物理的な配布物のアーティファクト (即ち、ディスク上のファイル)。
- 配布パッケージ#
:term:`モジュール <Module>`すなわちPythonの :term:`パッケージ <Import Package>`や、ある :term:`Release`を配布するために使われるその他のリソースファイルを内部に含むバージョン付きアーカイブファイル。アーカイブファイルはエンドユーザがインターネットからダウンロードしてインストールするものです。
配布パッケージは単語ひとつで「パッケージ」や「配布物」と呼ばれることもしばしばですが、本ガイドでは、 :term:`インポートパッケージ <Import Package>`(これも通常は単に「パッケージ」と呼ばれます)や他の種類の配布物(例えばLinuxディストリビューションやPython言語の配布物)でよく単語ひとつの「配布物」と呼ばれるものとの混同を避けるために明確に述べる必要がある場合には、長い方の用語を用いることがあります。
- 卵#
Wheel によって既に置き換えられていますが、 ビルド済配布物 フォーマットは、 Setuptools によって導入されました。詳細については、 egg フォーマット を見てください。
- 拡張モジュール#
:term:`モジュール <Module>`とは、Pythonの実装のうちの低レベル言語で書かれた部分で、C/C++で書かれたCythonやJavaで書かれたJythonが該当する。典型的には動的にロードできるコンパイル済みのファイルをひとつ含んでいて、Unix上では共有オブジェクトファイル(.so)、Windows上ではDLL(拡張子.pydを与えられる)のPython拡張、Jython拡張ではJavaのクラスファイルの形を取る。
- インポートパッケージ#
直接に、あるいは何段階になっても良いが、他のパッケージを組み込んで使うようなPythonモジュール。
インポートパッケージは、より普通には「パッケージ」という１単語の用語で呼ばれますが、本ガイドでは、同様に単に「パッケージ」と呼ばれることが普通である :term:`配布物パッケージ <Distribution Package>`との混同を避けるために必要な場合には、長い方の用語を用いることにします。
- インストール済みのプロジェクト#
インストール済みパッケージを記録する の仕様の中に記述されているところの、Python インタープリタまたは 仮想環境 とともに用いられるべくインストールされた プロジェクト。
- 既知の良好なセット#
(KGSとは)相互に互換性のある特定のバージョンの配布物の集合。典型的には、テストスイートで全てのテストに合格して実行できるようなパッケージの特定の組み合わせが既知の良好なセット(KGS)であると宣言されます。この用語は、個々の配布物を複数組み合わせて構成されるフレームワークやツールキットで共通して用いられます。
- モジュール#
Pythonにおけるソースコード再利用の基本的な単位で、 :term:`Pure Module`か :term:`Extension Module`の二つのタイプのうちのいずれか。
- パッケージインデックス#
:term:`パッケージ <Distribution Package>`の発見・消費(訳註、意訳になるが検索・ダウンロードが適切か)を自動化するwebインターフェイスを伴った配布物のリポジトリ。
- プロジェクト単位の索引#
ある プロジェクト。
- プロジェクト#
ライブラリ、フレームワーク、スクリプト、プラグイン、アプリケーション、ないし一連のデータもしくはその他のリソース、または、これらの組み合わせで :term:`配布物 <Distribution Package>`として意図的にパッケージされたもの。
ほとんどのプロジェクトで PEP 518 ``build-system``として :ref:`distutils`か :ref:`setuptools`を用いて :term:`配布物 <Distribution Package>`を作成しますので、現時点でプロジェクトを定義するもうひとつの実践的な方法は、プロジェクトのソースコードの一番上のディレクトリに :term:`pyproject.toml`や :term:`setup.py`または :term:`setup.cfg`のファイルを含む何ものかというものです。
Pythonにおけるプロジェクトは、 :term:`PyPI <Python Package Index (PyPI)>`に登録される一意の名前を持っていなければなりません。そして、プロジェクトはそれぞれひとつまたはより多くの :term:`リリース <Release>`を含んでいて、各リリースはひとつまたはより多くの :term:`配布物 <Distribution Package>`を内包しています。
そのプロジェクトを稼働させるためにインポートされるパッケージの名前に因んでプロジェクトに名前をつけるのが普通であるという強い慣習があることを覚えておいてください。しかしながら、常にそうしなければならないわけではありません。「なんとか」というプロジェクトから配布物をインストールしていながらも、「かんとか」(訳註、「なんとか」とは無関係の別の名前の例)という名前でのみインポート可能なパッケージを提供することは可能です。
- プロジェクトのルートディレクトリ#
- プロジェクトソースコードツリー#
ソースコード配布物 や ビルド済配布物 にパッケージされる前の生のソースコードを含んだ、開発に使われる プロジェクト のディスク上でのフォーマット。
- プロジェクトソースのメタデータ#
プロジェクト の ソースコードツリー 内でパッケージ作者が定義したメタデータで、プロジェクトの ビルドバックエンド が ビルド済メタデータ 内の コアとなるメタデータのフィールド <Core Metadata Field へ変換するもの。 Pyproject のメタデータ の形か、ツール特有のフォーマット (
pyproject.toml内の[tool]テーブル、または、ツール独自の設定ファイル) で書くことができます。- 純粋なモジュール#
Pythonで書かれていて単一の``.py``ファイル(とおそらくは対応する``.pyc``ファイルや``.pyo``ファイル)に収められた モジュール。
- Pyproject のメタデータ#
ref:プロジェクトのメタデータを宣言する の仕様で定義されており、 PEP 621 で初めて登場した プロジェクトソースのメタデータ のフォーマットで、 pyproject.toml ファイルの
[project]テーブルの下の プロジェクトソースのメタデータ として格納されるもの。pyproject.toml内の[tool]テーブルの下にあるツール特有のソースメタデータでは ない ということに注意。- Pyproject のメタデータキー#
pyproject.toml内の[project]テーブルの中にあるトップレベルの TOML キー; Pyproject のメタデータ の一部。 コアとなるメタデータのフィールド <Core Metadata Field とは異なる点に注意。- Pyproject のメタデータサブキー#
Pyproject メタデータのキー のテーブルの値の下にある第２層の TOML キー。
- Pythonパッケージングオーソリティ(PyPA)#
PyPAは、Pythonのパッケージングに関係する多くのプロジェクトを維持管理する作業グループです。その活動の一環として papa.io を維持管理しており、 GitHub と Bitbucket に関連プロジェクトを置くとともに、 distutils-sig メーリングリスト と Python談話フォーラム で議論を進めています。
- Pythonパッケージインデックス (PyPI)#
PyPI は、Pythonコミュニティにとってデフォルトの :term:`Package Index`です。ここから配布物を取り出し、また、配布するためにすべてのPython開発者に開かれています。
- pypi.org#
pypi.org は、 Python パッケージインデックス(PyPI) のためのドメイン名です。2017年にそれまでのドメイン名である
pypi.python.orgを置き換えました。 :ref:`warehouse`を使っています。- pyproject.toml#
- リリース#
ある特定の時点における :term:`プロジェクト <Project>`のスナップショットで、バージョン識別子付きのもの。
リリースを作成することは、複数の 配布物 を公開することを伴います。例えば、あるプロジェクトのバージョン1.0がリリースされたならば、ソースコード配布物とWindowsインストーラ付配布物の両方が利用可能となっているという具合です。
- 要求事項#
インストールされる パッケージ の仕様。 PYPA が推奨するインストーラである pip では、「要求事項」とも解釈できる仕様を様々な様式で書くことを許容しています。詳細については、 pip install の項を参照してください。
- 要求事項識別子#
パッケージインデックス <Package Index>`からパッケージをインストールするために :ref:`pip で用いられる様式。この様式の EBNF 文法構造については、 依存関係指定子 を見てください。例えば、 "foo>=1.3" は要求事項識別子であり、 "foo" の部分がプロジェクトの名称で、 ">=1.3" の部分は バージョン指定子 です
- Requirementsファイル#
pip`を用いてインストールできるように :term:`要求事項 を記したファイル。詳しい情報は、 pip のドキュメントの pip:Requirementsファイル をみてください。
- setup.py#
- setup.cfg#
distutils`や :ref:`setuptools で使われるプロジェクトの仕様を記したファイル。 :term:`pyproject.toml`も見てください。
- ソースコードアーカイブ#
ソースコード配布物 や ビルド配布物 という用語を作る前には、:term:`リリース <Release>`向けに生のソースコードを収めたアーカイブのことをこう呼んでいた。
ソースコード配布物 (またはsdist)#pip のようなツールによるインストールや ビルド済配布物 の生成のために必要となるメタデータや必須のソースファイルを提供する 配布物 アーカイブ フォーマット (通常は
python -m build --sdistを使って生成されます) 。もっと情報が欲しければ、 パッケージフォーマット を見てください。- システムパッケージ#
rpmやdpkgのように、オペレーティングシステムに固有のフォーマットで提供されるパッケージ。
- バージョン指定子#
要求事項指定子 のバージョン部分。例えば、"foo>=1.3" の中の ">=1.3" の部分。 Python のパッケージングで現在サポートされている識別子の完全な記述については、 バージョン指定子の仕様 を読んでください。この仕様のサポートは、 Setuptools v8.0 と pip v6.0 で実装されました。
- 仮想環境#
システム全体からではなく、ある特定のアプリケーションだけから使えるようにパッケージをインストールすることができる、隔離されたPython環境。詳細は :ref:`仮想環境の生成と使用 <Creating and using Virtual Environments`を参照してください。
- Wheel フォーマット#
- Wheel#
標準的な ビルド済配布物 フォーマットで、当初は PEP 427 で導入され、 バイナリ配布物のフォーマット 仕様で定義されたもの。詳しくは パッケージフォーマット を見てください。参照実装である Wheel プロジェクト と混同しないように。
- Wheel プロジェクト#
Wheel フォーマット の PyPA による参照実装; wheel 参照。
- 動作可能セット#
一連のインポート可能な 配布物。これらは
sys.path変数から検索できる配布物です。あるプロジェクトには、高々(訳註、at mostではなくat least、すくなくとも、か。)ひとつの 配布物 が動作可能セットにあります。