用語集¶
- バイナリ配布物¶
ビルド済配布物 の特定の種類で、コンパイル済みの拡張部分を含むもの。
- ビルドバックエンド¶
ソースコードツリー を受け取って、そこから ソースコード配布物 や ビルド済配布物 をビルドするライブラリ。ビルドの作業は、 フロントエンド によってバックエンドに委任されます。すべてのバックエンドが標準化されたインタフェースを提供します。
ビルドバックエンドの例としては、 flit の flit-core 、 hatchのhatchling 、 Maturin 、 meson-python 、 scikit-build-core 、 Setuptools があります。
- ビルドフロントエンド¶
任意のソースコードツリーまたは ソースコード配布物 を入力として、それらからソースコード配布物または wheels をビルドするためにユーザが走らせるであろうツール。実際のビルド作業は、それぞれのソースコードツリーの ビルドバックエンド に委任されます。
- ビルド済配布物¶
配布物 フォーマットは、インストールするためにターゲットとなるシステムの適切な位置に移動させることに必要となるファイルやメタデータだけを含んでいます。 Wheel はそのようなフォーマットですが、インストールできるようになる前にビルド段階が必須となると言う点で Source Distribution (or "sdist") はそうではありません。このフォーマットであることは、 Python のファイル群があらかじめコンパイルされた状態でなければならないということを意味しません (Wheel では意図的にコンパイル済みの Python ファイル群を含まないようになっています)。より詳しくは パッケージフォーマット を見てください。
- ビルドされたメタデータ¶
インストールされた プロジェクト (
METADATAファイル) や 配布物アーカイブ ( Sdist の中のPKG-INFOや Wheel 内のMETADATA) の内部に含まれる場合に コアとなるメタデータ が具体的な形式を取ることになります。- コアとなるメタデータ¶
仕様 および コアとなるメタデータのフィールドs において、 配布パッケージ あるいは インストール済みのプロジェクト の鍵となる静的なアトリビュートを記述するものを定義しています。
- コアとなるメタデータのフィールド¶
コアとなるメタデータ の仕様の中で定義され、 ビルド済みのメタデータ の中に保存される、単一のキー・バリューペア (または、複数の使用方法のあるフィールドについては、一連の同名のキー・バリューペア)。特筆すべきことに、 Pyproject メタデータキー とは区別される。
- 配布物アーカイブ¶
配布パッケージ のための物理的な配布物のアーティファクト (即ち、ディスク上のファイル)。
- 配布パッケージ¶
モジュール すなわちPythonの パッケージ や、ある Release を配布するために使われるその他のリソースファイルを内部に含むバージョン付きアーカイブファイル。アーカイブファイルはエンドユーザがインターネットからダウンロードしてインストールするものです。
配布パッケージは１単語で「パッケージ」もしくは「配布物」と呼ばれることもしばしばですが、本ガイドでは、 インポートパッケージ (これも通常は単に「パッケージ」と呼ばれます) や、しばしば「配布物」の１単語で呼ばれるもうひとつの種類の配布物 (例えばLinuxディストリビューションやPython言語の配布物) との混同を避けるために明確に述べる必要がある場合には、長い方の用語を用いることがあります。これらの相違に関する詳細については、 配布パッケージ vs. インポートパッケージ を見てください。
- 卵¶
Wheel によって既に置き換えられていますが、 ビルド済配布物 フォーマットは、 Setuptools によって導入されました。詳細については、 egg フォーマット を見てください。
- 拡張モジュール¶
モジュール とは、Pythonの実装のうちの低レベル言語で書かれた部分で、C/C++で書かれたCythonやJavaで書かれたJythonが該当する。典型的には動的にロードできるコンパイル済みのファイルをひとつ含んでいて、Unix上では共有オブジェクトファイル(.so)、Windows上ではDLL(拡張子.pydを与えられる)のPython拡張、Jython拡張ではJavaのクラスファイルの形を取る。
- インポートパッケージ¶
直接に、あるいは何段階になっても良いが、他のパッケージを組み込んで使うようなPythonモジュール。
インポートパッケージは、より普通には「パッケージ」という１単語の用語で呼ばれますが、本ガイドでは、同様に単に「パッケージ」と呼ばれることが普通である 配布物パッケージ との混同を避けるために必要な場合には、長い方の用語を用いることにします。これらの違いの細かな部分については、 配布パッケージ vs. インポートパッケージ を見てください。
- インストール済みのプロジェクト¶
インストール済みのプロジェクトを記録する の仕様の中に記述されている、Python インタープリタまたは 仮想環境 と一緒に使用するためにインストールされた プロジェクト 。
- 既知の良好なセット¶
相互に互換性のある特定のバージョンの配布物の集合。典型的には、テストスイートで全てのテストに合格して実行できるようなパッケージの特定の組み合わせが既知の良好なセットであると宣言されます。この用語は、個々の配布物を複数組み合わせて構成されるフレームワークやツールキットで共通して用いられます。
- ライセンス分類詞 <License Classifier>¶
ライセンス
License::で始まる (コアとなるメタデータ 仕様の中で 記述されている とおりの) `` PyPI の Trove classifier プロジェクト。- ライセンス表現¶
- SPDX 表現¶
ひとつかそれ以上の SPDX ライセンス識別子 (複数の場合もあり) を含む、正当な SPDX ライセンス表現のシンタックスを伴う文字列で、 配布物アーカイブ のライセンス(群) を記述し、どのように相互に関係するのかを表現するもの。例:
GPL-3.0-or-later・MIT AND (Apache-2.0 OR BSD-2-Clause)- ライセンス識別子¶
- SPDX 識別子¶
元々は PEP 639 で仕様化された、正当な SPDX の短縮形式のライセンス識別子。これには、すべての正当な SPDX 識別子と、 SPDX 仕様を満足するカスタムの
LicenseRef-[idstring]文字列が含まれます。例:MIT・GPL-3.0-only・LicenseRef-My-Custom-License- モジュール¶
Pythonにおけるソースコード再利用の基本的な単位で、 :term:`Pure Module`か :term:`Extension Module`の二つのタイプのうちのいずれか。
- パッケージインデックス¶
:term:`パッケージ <Distribution Package>`の発見・消費(訳註、意訳になるが検索・ダウンロードが適切か)を自動化するwebインターフェイスを伴った配布物のリポジトリ。
- プロジェクト単位の索引¶
プライベートまたは非公式の パッケージ索引 で、そのプロジェクトの依存関係を解決するために、好ましいまたは要求される時に、特定の プロジェクト によって示されたもの。
- プロジェクト¶
ライブラリ、フレームワーク、スクリプト、プラグイン、アプリケーション、ないし一連のデータもしくはその他のリソース、または、これらの組み合わせで 配布物 として意図的にパッケージされたもの。
ほとんどのプロジェクトで 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 のメタデータ¶
pyproject.toml の仕様 の仕様で定義されていて、 PEP 621 で初めて登場した プロジェクトソースのメタデータ で、 pyproject.toml ファイルの
[project]テーブルの下の Pyproject Metadata Keys として格納されるもの。pyproject.toml内の[tool]テーブルの下にあるツール特有のソースメタデータでは ない ということに注意。- Pyproject のメタデータキー¶
pyproject.toml内の[project]テーブルの中にあるトップレベルの TOML キー; Pyproject のメタデータ の一部。 コアとなるメタデータのフィールド とは異なる点に注意。- Pyproject のメタデータサブキー¶
Pyproject メタデータのキー のテーブルの値の下にある第２層の TOML キー。
- Pythonパッケージングオーソリティ(PyPA)¶
PyPAは、Pythonのパッケージングに関係する多くのプロジェクトを維持管理する作業グループです。その活動の一環として papa.io を維持管理しており、 GitHub に関連プロジェクトを置くとともに、 distutils-sig メーリングリスト と Python談話フォーラム で議論を進めています。
- Pythonパッケージインデックス (PyPI)¶
PyPI は、Pythonコミュニティにとってデフォルトの Package Index です。ここから配布物を取り出し、また、配布するためにすべてのPython開発者に開かれています。
- pypi.org¶
pypi.org は、 Python パッケージインデックス(PyPI) のためのドメイン名です。2017年にそれまでのドメイン名である
pypi.python.orgを置き換えました。 Warehouse を使っています。- pyproject.toml¶
- リリース¶
ある特定の時点における プロジェクト のスナップショットで、バージョン識別子付きのもの。
リリースを作成することは、複数の 配布物 を公開することを伴います。例えば、あるプロジェクトのバージョン1.0がリリースされたならば、ソースコード配布物とWindowsインストーラ付配布物の両方が利用可能となっているという具合です。
- 要求事項¶
インストールされる パッケージ の仕様。 PYPA が推奨するインストーラである pip では、「要求事項」とも解釈できる仕様を様々な様式で書くことを許容しています。詳細については、 pip install の項を参照してください。
- 要求事項識別子¶
パッケージインデックス からパッケージをインストールするために pip で用いられる様式。この様式の EBNF 文法構造については、 依存関係指定子 を見てください。例えば、 "foo>=1.3" は要求事項識別子であり、 "foo" の部分がプロジェクトの名称で、 ">=1.3" の部分は バージョン指定子 です
- Requirementsファイル¶
pip を用いてインストールできるように 要求事項 を記したファイル。詳しい情報は、 pip のドキュメントの pip:Requirementsファイル をみてください。
- ライセンスディレクトリのルート¶
- ライセンスディレクトリ¶
プロジェクトソースツリー 、 配布物アーカイブ 、または、 インストール済みのプロジェクト の中で、その下にライセンスファイル群を保存するディレクトリ。 プロジェクトソースツリー または ソースコード配布物 (または "sdist") では、これは、 プロジェクトルートディレクトリ です。 ビルド済配布物 や インストール済みのプロジェクト では、これは、 それぞれ、wheel アーカイブの
.dist-info/licenses/ディレクトリであるか、プロジェクトフォルダーです。また、License-File内の Core Metadata Field に記録されているパスはルートディレクトリからの相対パスです。- setup.py¶
- setup.cfg¶
distutils や Setuptools で使われるプロジェクトの仕様を記したファイル。 pyproject.toml も見てください。
- ソースコードアーカイブ¶
ソースコード配布物 や ビルド配布物 という用語を作る前には、リリース 向けに生のソースコードを収めたアーカイブのことをこう呼んでいた。
ソースコード配布物 (または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、すくなくとも、か。)ひとつの 配布物 が動作可能セットにあります。