コアとなるメタデータの仕様

このページは、 2025年9月に承認されたバージョン 2.5 を記述しています。

この後の仕様の中で定義されるフィールドは、正当かつ完全であって、変更の可能性がないものと見做されるべきです。必須のフィールドは以下の通り:

  • Metadata-Version

  • Name

  • Version

これら以外のすべてのフィールドは必須のものではありません。

(wheels および インストール済みのプロジェクト の両文書に含まれる) メタデータのための標準的なファイルフォーマットは、電子メールのヘッダーのフォーマットに基いています。しかしながら、電子メールのフォーマットは何度か修正が入っていますが、正確にはどの電子メールの RFC がパッケージングのメタデータに適用されるのかについては指定がありません。精密な定義が欠落しているので、標準ライブラリの email.parser モジュールが compat32 のポリシーを用いて読み込むことができるものを実務上の標準として設定しています。

メタデータをバイト列 (例えばファイルに保存するために) にシリアル化する際にはいつでも、文字列を UTF-8 エンコーディングを用いてシリアル化しなければなりません。

PEP 566 でメタデータを JSON 互換の辞書型に変換する一つの方法を定義していますが、標準の交換フォーマットとしてはまだ使われていません。既に何年間も使われてきた既存のパッケージと共に動作するツールが必要なので、新しいフォーマットに移行することは困難なのです。

注釈

古い形式のメタデータを翻訳する: PEP 566 では、バージョン指定子フィールドのフォーマット仕様がよく用いられている公開ツール群で使われる構文を受け入れる (正確にはバージョン指定子が丸括弧で囲まれていなければならないという要求事項を削除することによって) ようにと緩められました。メタデータを使う側としては、メタデータファイルが名ばかりのものとなっている 2.1 よりも前のバージョンであってさえも、もっと寛容なフォーマット規則を使いたいかもしれません。

Metadata-Version

バージョン 1.0 で追加.

ファイルフォーマットのバージョン番号; 合法な値は次のとおり"1.0", "1.1", "1.2", "2.1", "2.2", "2.3", "2.4" および "2.5"。

メタデータを処理する自動化ツールは、 metadata-version が自身のサポートする最大のものより大きい場合には警告を行うべきであり、かつ、 metadata-version が自身のサポートする最大のメジャーバージョンより大きいメジャーバージョンを持つ場合には異常終了しなければなりません (バージョン指定子仕様 に記述されている通り、メジャーバージョンとはバージョンのうち最初のドットよりも前の部分です) 。

より広く互換性を保つために、ビルドツールは、必要なフィールドをすべて含む前提で最も古いバージョンのメタデータ仕様を使って配布物のメタデータを生成するという選択を行なっても構いません。

例:

Metadata-Version: 2.4

Name

バージョン 1.0 で追加.

バージョン 2.1 で変更: 名称のフォーマット から採用したフォーマットに対する制限を追加した。

配布物の名称。name フィールドは配布物の最も基本的な識別子です。 名称フォーマット仕様 を満たしていなければなりません。

例:

Name: BeagleVote

比較の目的のためにも、名前は比較の前に 正規化 されているべきです。

Version

バージョン 1.0 で追加.

配布物のバージョン番号を格納する文字列。このフィールドは バージョン指定子仕様 で規定されるフォーマットでなければなりません。

例:

Version: 1.0a2

Dyanamic (複数回の使用可)

バージョン 2.2 で追加.

別のコアとなるメタデータのフィールドの名前を包含した文字列。フィールド名の Name ・ Version ・ Metadata-Version をこのフィールドに指定してはなりません。

ソースコード配布物のメタデータ中に見つかった場合には、以下の規則を適用します:

  1. フィールドが Dynamic と マークされていない 場合は、 sdist からビルドされたどの wheel であっても、そのフィールドの値が sdist での値と一致しなければなりません。そのフィールドが sdist には存在せず、かつ、 Dynamic とマークされていない場合には、そのようなフィールドは wheel に出現してはなりません。

  2. フィールドが Dynamic とマークされている場合、 (ひとつも存在しない場合も含めて) sdist からビルドされた wheel 内のどんな正当な値を取っても構いません。

sdist のメタデータバージョンがバージョン 2.2 よりも古い場合には、すべてのフィールドが Dynamic であると指定されたかのように (つまり、その sdist からビルドされた wheel のメタデータに何も特別な制約がないかのように) 取り扱うべきです。

ソースコード配布物を除くすべての文脈で、 Dynamic は情報提供の目的のみであり、そのフィールドの値がビルドの際に計算されたものであって、 sdist や同じプロジェクトでも他の wheel ファイルでは異なる場合があることを示します。

事前ビルド済の wheel を持っているなら、一部の wheel は sdist から直接にビルドされるわけではなく、既存の wheel (例えば、 auditwheel ツールはこれをやりますし、 PyPI 用に wheel をビルドするときには一般的に使われます)から変換して作られるので、 動的 <Dynamic> とマークされていないフィールドが他の wheel でも同じ値を持つであろうということを、特に覚えておいてください。このような変換には、 (動的ではないメタデータであってさえも) メタデータの変更をも含む かもしれません 。同様に、 sdis と、自分でその sdist から ビルドしたわけではない wheel が手元にある時、 動的 とマークされていないフィールドであってさえも、 wheel のメタデータが sdist のそれと一致すると仮定することはできません。

Dynamic の詳細かつ完全な意味は PEP 643 に記述されています。

Platform (複数回の使用可)

バージョン 1.0 で追加.

Platform の仕様は、その配布物がサポートするオペレーティングシステムを記述したもので、 "Operating System" Trove 分類子には記載されていないもの。後述の "分類子 <Classifier>" を見てください。

例

Platform: ObscureUnix
Platform: RareDOS

Supported-Platform (複数回の使用可)

バージョン 1.1 で追加.

PKG-INFO ファイルを含むバイナリ配布物は、内包するメタデータの中の Supported-Platform フィールドを使って当該バイナリ配布物がどの OS や CPU 向けにコンパイルされたかを指定することになるでしょう。 Supported-Platform フィールドのセマンティクスは PEP には定義されたものがありません。

例:

Supported-Platform: RedHat 7.2
Supported-Platform: i386-win32-2791

Summary

バージョン 1.0 で追加.

その配布物が何をするものかを１行で記述した要約。

例:

Summary: A module for collecting votes from beagles.

説明

バージョン 1.0 で追加.

バージョン 2.1 で変更: このフィールドの代わりにメッセージ本体で指定しても構いません。

配布物に関する長めの説明文で、いくつかの段落に渡ってもかまいません。取扱説明書並みの記述をするべきではありませんが、メタデータを扱うソフトウェアはこのフィールドに最大長さがあるものと仮定すべきではありません。

このフィールドの内容は、 reStructuredText マークアップ [1] を使って書いても構いません。メタデータを取り扱うプログラムの側ではマークアップをサポートしてもしなくてもかまわず、サポートしない場合にはこのフィールドの内容をそのまま表示することも可能です。つまり、作者の側は、自分が採用するマークアップ言語については保守的であるべきだということになります。

空行および RFC 822 に従う字下げをサポートするために、すべての CRLF 文字には７個の空白文字と１個のパイプ文字 ("|") がこの順に並ぶ文字列が後続しなければなりません。その結果として、Description フィールドが RFC 822 構文解析器 [2] で解析可能な形の改行可能なフィールドにエンコードされます。

例:

Description: This project provides powerful math functions
        |For example, you can use `sum()` to sum numbers:
        |
        |Example::
        |
        |    >>> sum(1, 2)
        |    3
        |

このエンコーディングが意味するところは、その折り畳まれたフィールドをRFC822 読み取り器で読み取る時には、CRLF と７個の空白文字とそれに引き続くパイプ文字が出現するたびにそれを単独の CRLF に置き換えなければならないということです。

代替策として、配布物に関する説明を代わりにメッセージボディに書く (つまり、字下げやその他の特別なフォーマットを使わずに、ヘッダの並びの後の完全な空行に続けて書く) こともできます。

Description-Content-Type

バージョン 2.1 で追加.

配布物の説明で使われるマークアップ構文 (もしあれば) を述べる文字列で、ツールの側が頭の良いやり方で説明を表示することができます。

歴史的には PyPI はプレーンテキストおよび reStructuredText (reST) での description をサポートし、 reST を HTML として表示することができました。しかしながら、多くのソースコード管理サイトが Markdown の README を表示するようになったので、配布物の作者たちが description を Markdown (RFC 7763) で書くことが普通になり、作者たちはそのファイルを description として再利用するようになってきました。 PyPI はこのフォーマットを認識せず、従って description の内容を正しく表示することができませんでした。その結果、 PyPI 上の多くのパッケージで Markdown がプレーンテキストとして、もっと悪い場合には reST として解釈して、惨めな表示になっていました。このフィールドは配布物の作者がその description のフォーマットを指定できるようにしますので、 PyPI やその他のツールが Markdown やその他のフォーマットを正しく表示できるようになる可能性を広げます。

このフィールドのフォーマットは HTTP (すなわち RFC 1341) における Content-Type ヘッダのそれと同じです。端的に言えば、これは type/subtype の部分を持っていて、オプションとしていくつかのパラメータを取ることができるというものです:

フォーマット

Description-Content-Type: <type>/<subtype>; charset=<charset>[; <param_name>=<param value> ...]

type/subtype 部分はいくつかの正当な値を取ります:

  • text/plain

  • text/x-rst

  • text/markdown

charset パラメータは、description のキャラクターのエンコーディングを指定するために使われます。唯一の正当な値は UTF-8 です。省略時には UTF-8 であるものと仮定します。

サブタイプを選択するために他のパラメータが指定される場合もあります。例えば、 markdown サブタイプを指定する際に、使われている Markdown の異種 (指定がない場合にはデフォルトでは GFM) を指定することができるオプションの variant パラメータが存在します。現時点ではふたつの異種が認識されます:

例:

Description-Content-Type: text/plain; charset=UTF-8

例:

Description-Content-Type: text/x-rst; charset=UTF-8

例:

Description-Content-Type: text/markdown; charset=UTF-8; variant=GFM

例:

Description-Content-Type: text/markdown

Description-Content-Type が指定されていない場合には、アプリケーションとしては、まず text/x-rst; charset=UTF-8 として表示を試み、正当な rst ではない場合に text/plain にフォールバックするべきです。

Description-Content-Type が認識できない値である場合には、内容の型が text/plain であるものと仮定します (とはいえ、認識できない値であれば何であっても PyPI が拒否することになるでしょう) 。

Description-Content-Type が text/markdown で、 variant が指定されない場合や認識できない値が指定された場合には、 variant が GFM であるものと仮定されます。

上記の最後の例を見ると charset はデフォルトでは UTF-8 であり、 variant はデフォルトでは GFM ですので、それ以前の例と同等であるということになります。

キーワード

バージョン 1.0 で追加.

より大きなカタログで配布物を検索する助けとなるべく使用される、コンマで区切られた追加のキーワードのリスト。

例:

Keywords: dog,puppy,voting,election

注釈

以前にお見せした仕様ではキーワードを区切るのに空白文字を使っていましたが、 distutils と setuptools はコンマで区切ります。これらのツールは多年に渡って非常に広く使われていますので、仕様をデファクト標準に合わせる形で更新する方が簡単でした。

Author

バージョン 1.0 で追加.

少なくとも作者の名前を含む文字列で、連絡先となる情報を追加しても構いません。

例:

Author: C. Schultz, Universal Features Syndicate,
        Los Angeles, CA <cschultz@peanuts.example.com>

Author-email

バージョン 1.0 で追加.

作者の電子メールアドレスを含む文字列。 RFC-822 の From: ヘッダの記述形式として正当な形で名前と電子メールアドレスを含んでいても構いません。

例:

Author-email: "C. Schultz" <cschultz@example.com>

RFC-822 によれば、このフィールドには、複数の電子メールアドレスをコンマで区切って記述しても構いません

Author-email: cschultz@example.com, snoopy@peanuts.com

メンテナ

バージョン 1.2 で追加.

少なくともメンテナの名前を含む文字列で、連絡先となる情報を追加しても構いません。

当該プロジェクトが元々の作者とは異なる誰かによって保守されている場合にこのフィールドを使うことを想定しているということを覚えておいてください: もし Author と同一人物であれば、このフィールドを省略するべきです。

例:

Maintainer: C. Schultz, Universal Features Syndicate,
        Los Angeles, CA <cschultz@peanuts.example.com>

Maintainer-email

バージョン 1.2 で追加.

メンテナの電子メールアドレスを含む文字列。 RFC-822 の From: ヘッダの記述形式として正当な形で名前と電子メールアドレスを含んでいても構いません。

当該プロジェクトが元々の作者とは異なる誰かによって保守されている場合にこのフィールドを使うことを想定しているということを覚えておいてください: もし Author-email と同一であれば、このフィールドを省略するべきです。

例:

Maintainer-email: "C. Schultz" <cschultz@example.com>

RFC-822 によれば、このフィールドには、複数の電子メールアドレスをコンマで区切って記述しても構いません

Maintainer-email: cschultz@example.com, snoopy@peanuts.com

License

バージョン 1.0 で追加.

バージョン 2.4 で非推奨: License-Expression に従って。

警告

Metadata 2.4 の時点では、 License と License-Expression は、相互に排他的に扱われます。両者が同時に指定された場合は、メタデータをパースするツールは License を無視するでしょうし、 PyPI はアップロードを拒否するでしょう。 PEP 639 をみてください。

"License" Trove 分類子から選択したものではないライセンスの場合は、配布物をカバーするライセンスを示すテキスト。後述の "Classifier" を見てください。このフィールドは、 Classifier フィールドを経由して名指しされたライセンスの特定のバージョンを指定したり、そのようなライセンスに対する変種や例外事項を示したりするのに使っても構いません。

例

License: This software may only be obtained by sending the
        author a postcard, and then the user promises not
        to redistribute it.

License: GPL version 3, excluding DRM provisions

License-Expression

バージョン 2.4 で追加.

ライセンス表現 で指定された、正当な SPDX ライセンス表現 であるテキスト文字列。

このフィールドの表現が、このフィールド (例えば、 ソースコード配布物 や Wheel) を伴うメタデータを含む 配布物アーカイブ にだけ適用されるのであって、プロジェクト全体やプロジェクトに関係する (他の配布物アーカイブを含む) 他のファイルことに注意してください。

例

License-Expression: MIT
License-Expression: BSD-3-Clause
License-Expression: MIT AND (Apache-2.0 OR BSD-2-Clause)
License-Expression: MIT OR GPL-2.0-or-later OR (FSFUL AND BSD-2-Clause)
License-Expression: GPL-3.0-only WITH Classpath-Exception-2.0 OR BSD-3-Clause
License-Expression: LicenseRef-Special-License OR CC0-1.0 OR Unlicense
License-Expression: LicenseRef-Proprietary

License-File (複数回使用)

バージョン 2.4 で追加.

各エントリは、ライセンス関連のファイルのパスの文字列表現です。パスは、プロジェクトのソースコードツリー内に位置していて、プロジェクトのルートディレクトリからの相対ぱすです。詳細については、 PEP 639 をみてください。

例

License-File: LICENSE
License-File: AUTHORS
License-File: LICENSE.txt
License-File: licenses/LICENSE.MIT
License-File: licenses/LICENSE.CC0

Classifier (複数回の使用可)

バージョン 1.1 で追加.

それぞれのエントリは、当該配布物を分類する値をひとつ与える文字列です。分類子については PEP 301 に記述されていて、The Python Package Index は 現在定義されている分類子 という動的なリストを公開しています。

注釈

License:: 分類子の使用は Metadata 2.4 の時点で非推奨になっており、代わりに License-Expression を使ってください。 PEP 639 を見てください。

このフィールドでは、セミコロンの後に環境指標を続けても構いません。

例

Classifier: Development Status :: 4 - Beta
Classifier: Environment :: Console (Text Based)

Requires-Dist (複数回の使用可)

バージョン 1.2 で追加.

バージョン 2.1 で変更: フィールドの仕様は、人気のある公開ツール群が用いる構文を許容するように緩められました。

それぞれのエントリは、この配布物が要求する他の distutils のプロジェクトを名指しする文字列を含みます。

要求事項を示す文字列のフォーマットは、１個から４個の部分を含みます:

  • Name: フィールドと同じフォーマットのプロジェクト名。これだけが必須部分です。

  • コンマ区切りの '追加の' 名前のリスト。これらは、追加的な依存先を必要とする特定の機能に応じて、要求されたプロジェクトによって定義されます。この名前は、 Provides-Extra: フィールドで指定された制約事項に従うものでなければなりません。

  • バージョン指定子。この部分をパースするツールはバージョンを囲む括弧を許容しなければならないが、生成する際には括弧を使ってはなりません。

  • セミコロンの後ろに環境マーカ。要求事項が必要となるのが指定された条件の時のみであることを示します。

プロジェクト名称は、 Python Package Index に出現する名前に対応していなければなりません。

バージョン指定子は バージョン指定子 に記述された規則に従っていなければなりません。

See 依存関係指定子 for full details of the allowed format.

例

Requires-Dist: pkginfo
Requires-Dist: PasteDeploy
Requires-Dist: zope.interface (>3.5.0)
Requires-Dist: pywin32 >1.0; sys_platform == 'win32'

Requires-Python

バージョン 1.2 で追加.

このフィールドは、配布物が互換性を持つ Python のバージョン (複数可) を指定します。インストールツールは、プロジェクトのインストールするべきバージョンを選択する時にこのフィールドを参照しても構いません。

値は、 バージョン指定子 で指定されたフォーマットでなければなりません。

例えば、ある配布物が f-strings を使っているなら、次のように指定することで Python < 3.6 上にインストールするのを抑止してもかまいません:

Requires-Python: >=3.6

このフィールドでは、環境マーカを後ろに付けることはできません。

Requires-External (複数回の使用可)

バージョン 1.2 で追加.

バージョン 2.1 で変更: フィールドの仕様は、人気のある公開ツール群が用いる構文を許容するように緩められました。

それぞれのエントリは、その配布物が使われるシステムにおける何らかの依存関係を記述する文字列です。このフィールドは、ダウンストリームプロジェクトの維持管理担当者向けにヒントを提供することを意図しており、 distutils 配布物にとっては何ら意味を持ちません。

要求事項の文字列のフォーマットは外部の依存先の名前で、必須ではありませんが括弧に入れたバージョンの宣言を後ろにつけても構いません。

このフィールドでは、セミコロンの後に環境指標を続けても構いません。

それらは非 Python のソフトウェアリリースを参照するものですので、このフィールドでのバージョン番号は バージョン指定子仕様 で指定されたフォーマットに適合することを 要求されていません : それらは、外部依存関係によって使われるバージョンスキームに対応するべきです。

使用される文字列に対して特に規則がないという点に注意してください。

例

Requires-External: C
Requires-External: libpng (>=1.5)
Requires-External: make; sys_platform != "win32"

Project-URL (複数回の使用可)

バージョン 1.2 で追加.

そのプロジェクトの閲覧可能な URL とラベルを含む文字列をコンマで区切ったもの。

例:

Project-URL: Bug Tracker, http://bitbucket.org/tarek/distribute/issues/

このラベルは32 文字以内のフリーテキストです。

PEP 753 に始まって、プロジェクトメタデータの消費者 (the Python Package Index など) は、 "well-known" なラベル、それは人間による消費のために展開される時には特定の特別な表現方法を与えることができますが、それを探索するために標準標準化プロセスを使うことができます。 メタデータ内のよく知られたプロジェクト URL を見てください。

Provides-Extra (複数回の使用可)

バージョン 2.1 で追加.

バージョン 2.3 で変更: 曖昧さ (すなわち正規化が要求されていない) を避けるために PEP 685 で制限された正当な値を。古めのメタデータのバージョンでは、 Name: を伴う行で値に制限が導入され、正規化規則も導入されました。

追加的な機能の名前を含む文字列。正当な名前は、 ASCII 小文字・ ASCII 数字・ハイフンからのみ構成されます。先頭と末尾は文字か数字でなければなりません。ハイフンは連続してはいけません。名前は次の正規表現にマッチしなければなりません (そうすることで曖昧さを排除します):

^[a-z0-9]+(-[a-z0-9]+)*$

指定された名前は、追加的な機能が要求されたか否かに応じて依存関係を構築するために使われます。

例:

Provides-Extra: pdf
Requires-Dist: reportlab; extra == 'pdf'

２番目の配布物は、角括弧の中に書くことで追加の依存先を要求し、コンマ (,) で区切ることで複数の機能を要求することができます。要求事項は、要求されたそれぞれの機能について評価され、配布物の要求する依存関係の組に追加されます。

例:

Requires-Dist: beaglevote[pdf]
Requires-Dist: libexample[test, doc]

test と doc という二つの名前は、順に自動化されたテストと説明文書の生成のために必要な依存先として予約されています。

Requires-Diet: のどこからも参照されていなくても、 Provides-Extra: を指定しても構いません。

古めのメタデータのバージョンでデータを書く時、比較を行う時には Name: フィールドに使われるのと同じ規則に従って正規化されなければなりません。ふたつの Provides-Extra: エントリが正規化後に衝突する場合には、メタデータを書き込むツールはエラーを発生させなければなりません。

メタデータの古めのバージョンから読み込む時、このフィールドの値が新しめのメタデータバージョンとして正当でない場合にツールが警告するべきです。コアとなるメタデータのバージョンで Name: に対する規則に照らして値が正当ではないとすればユーザは警告されるべきで、その値は曖昧さを避けるために無視されるべきです。古めのメタデータバージョンとして不当な名前を読み取った場合には、ツールはエラーを発出することを選択しても構いません。

Import-Name (複数回の使用可)

バージョン 2.5 で追加.

インストール時にプロジェクトが排他的に提供するインポートネームを含む文字列。指定されたインポートネームは、正当な Python 識別子でなければなりませんが、空でも構いません。このフィールドに列挙されたインポートネームは、プロジェクトがプロジェクトの同じバージョン用の 幾つかの プラットフォームにインストールされる時にインポート可能でなければなりません。これは、プロジェクトのあるリリースのすべての sdist と wheel を通じて、メタデータが守備一貫していなければならないと言うことを意味します。

インポートネームは、セミコロンの前後には空白文字がいくつあっても構わない形で、 (例えば ; private のように) セミコロンと "private" と言う用語を伴っても構いません。これによって、ツール類に対して、インポートネームがプロジェクトの公開の API の一部では無いことを伝えます。

プロジェクトは、そのプロジェクトによって独占的に提供される、最短インポートネームをすべて列挙するべきです。最短ネームがドットで区切られたネームであるなら、そのネームからトップレベルのネームに至る中間のネームもまた、 Import-Name および/または Import-Namespace に適切に列挙されるべきです。

あるプロジェクトが同じネームを Import-Name と Import-Namespace の両方に列挙している場合、ツール類は、曖昧さの故にエラーを発しなければなりません。

ツール類は、まさにインストールされようとしているふたつのプロジェクトがそれぞれの Import-Name エントリに重複したネームを列挙している時や、あるプロジェクトが Import-Name 内に持つエントリがもう一つのプロジェクトの Import-Namespace エントリと重複する時には、エラーを発生させるべきです。これは、プロジェクトが意図せずもう一つのプロジェクトのソースコードを覆い隠してしまうことを避けるためです。ツール類は、既にインストールされているプロジェクトとの間でインポートネームの重複が起きるような既存環境にプロジェクトをインストールする時には、警告するかエラーを発生させて構いません。

プロジェクトは、プロジェクトがインポートネームを持っていないこと (すなわち、配布物のファイルの中にはどんな種類の Python モジュールも存在しないこと) を表現するために、そのメタデータ内に空の Import-Name フィールドを持っても構いません。

(プロジェクトが古いメタデータバージョンを使っているために、もしくは、一つも指定していないために) プロジェクトが Import-Name メタデータを持たなくても構わないので、ツール類は、そのプロジェクトがどんなネームを提供するのかについて何も情報を持ちません。しかしながら、実際には、プロジェクトの大多数は、それらのインポートネームであろうものと一致するようなプロジェクト名を持っています。そういうことですので、何らかの答えが必要とされるなら、何らかの形で (例えば packaging.utils.canonicalize_name(name, validate=True).replace("-", "_") のように) インポート名を標準化したプロジェクト名を使うことが可能です。

例

Import-Name: PIL
Import-Name: _private_module ; private
Import-Name: zope.interface
Import-Name:

Import-Namespace (複数回の使用可)

バージョン 2.5 で追加.

インストール時にプロジェクトが提供したインポートネームだが、独占的に提供したものではないものを含んだ文字列。指定されたインポートネームは、 Python の正当な識別子でなければなりません。このフィールドは、複数のプロジェクトが同じインポート名前空間に貢献することができるように、名前空間パッケージ用に用いられます。同じインポートネームを Import-Namespace に列挙するプロジェクト群は、互いに隠蔽してしまうことなく一緒にインストールすることができます。

インポートネームは、セミコロンの前後には空白文字がいくつあっても構わない形で、 (例えば ; private のように) セミコロンと "private" と言う用語を伴っても構いません。これによって、ツール類に対して、インポートネームがプロジェクトの公開の API の一部では無いことを伝えます。

プロジェクトは、そのプロジェクトによって独占的に提供される、最短インポートネームをすべて列挙するべきです。最短ネームがドットで区切られたネームであるなら、そのネームからトップレベルのネームに至る中間のネームもまた、 Import-Name および/または Import-Namespace に適切に列挙されるべきです。

このフィールドに列挙されたインポートネームは、同じバージョンのプロジェクト用の いくつかの プラットフォームにプロジェクトがインストールされる時に、インポート可能でなければなりません。これは、プロジェクトのリリースのすべての sdist や wheel でメタデータが整合していなければならないということを意味しています。

あるプロジェクトが同じネームを Import-Name と Import-Namespace の両方に列挙している場合、ツール類は、曖昧さの故にエラーを発しなければなりません。

Import-Name では空値が許されますが、 Import-Namespace は空値であることはできないことに留意してください。

例

Import-Namespace: zope
Import-Name: _private_module ; private

稀に使われるフィールド

この節のフィールドは、 Linux のパッケージ管理システムにおける類似の機構に触発されて設計されましたが、 PyPI のような開放的なインデックスサーバの文脈でツールがどのように翻案するべきかが全く明らかではないので、現在ではほとんど使われません。

その結果として、人気のあるインストールツールでは完全に無視されていて、そのために今度はパッケージを公開する側でもこれらのフィールドを適切に設定しておく誘因がほとんどなくなっています。しかしながら、これらのフィールドは、情報提供の目的ではまだ潜在的に役に立つことと、細かく注釈をつけるようなパッケージリポジトリと組み合わせれば本来意図された目的に用いることができることから、メタデータの仕様には残されています。

Provides-Dist (複数回の使用可)

バージョン 1.2 で追加.

バージョン 2.1 で変更: フィールドの仕様は、人気のある公開ツール群が用いる構文を許容するように緩められました。

それぞれのエントリは、この配布物に含まれている Distutils プロジェクトの名前を文字列で含みます。このフィールドは、プロジェクトを特定する Name フィールドと後続するバージョンを 含んでいなければなりません: Name (Version) 。

配布物は、複数のプロジェクトが一緒に束ねられている場合には、それを示す追加の名前を持っていても構いません。例えば、 ZODB プロジェクトのソースコード配布物は、歴史的に transaction プロジェクトを包含していましたが、今では個別の配布物として利用可能です。そのようなソースコード配布物をインストールすると、 ZODB と transaction の両方の要求事項を満たします。

配布物は、また、個別に配布されているどんなプロジェクトにも紐付かない "仮想の" プロジェクト名を持っていても構いません: そのような名前は、複数のプロジェクトのうちのひとつで供給される抽象的な能力を示すために使われるかもしれません。例えば、複数のプロジェクトがとある ORM で使われる RDBMS バインディングを提供していても構いません: それぞれのプロジェクトが、他のプロジェクトが依存する時にはそのうちの高々１個だけがインストールされていれば十分な ORM-bindings を提供すると宣言していても構わないのです。

バージョンの宣言があっても構いませんが、 バージョン指定子 に記述された規則に従ったものでなければなりません。もし指定されていなければ、配布物のバージョン番号が暗黙理に使われます。

このフィールドでは、セミコロンの後に環境指標を続けても構いません。

例

Provides-Dist: OtherProject
Provides-Dist: AnotherProject==3.4
Provides-Dist: virtual_package; python_version >= "3.4"

Obsoletes-Dist (複数回の使用可)

バージョン 1.2 で追加.

バージョン 2.1 で変更: フィールドの仕様は、人気のある公開ツール群が用いる構文を許容するように緩められました。

それぞれのエントリは、この配布物が出たことで旧式化した、従ってこれらふたつのプロジェクトが同時にインストールされるべきではない distutils プロジェクトの配布物を記述する文字列を含みます。

バージョンの宣言があっても構いません。バージョン番号は バージョン指定子 で指定されたフォーマットでなければなりません。

このフィールドでは、セミコロンの後に環境指標を続けても構いません。

このフィールドの最もよくある使い方は、例えば Gorgon 2.3 が Torqued Python 1.0 の一部として組み込まれた時のように、プロジェクトの名前が変更された場合でしょう。 Torqued Python をインストールするなら、 Gorgon 配布物は削除されるべきです。

例

Obsoletes-Dist: Gorgon
Obsoletes-Dist: OtherProject (<3.0)
Obsoletes-Dist: Foo; os_name == "posix"

非推奨となったフィールド

非推奨となったフィールドは避けられるべきですが、しかし、まだ正当なメタデータフィールドです。それらは、将来のコアとなるメタデータ標準 (その時点では、取り除くのに先立って、メタデータのバージョン番号を指定したファイル内でのみ正当であるという状態になることでしょう) のバージョンで取り除かれるかもしれません。ツールの側では、ユーザに対して非推奨のフィールドが使われていることを警告するべきです。

Home-page

バージョン 1.0 で追加.

バージョン 1.2 で非推奨: PEP 753 に従って、代わりに Project-URL (複数回の使用可) を使ってください。

配布物のホームページを示す URL を含んだ文字列。

例:

Home-page: http://www.example.com/~cschultz/bvote/

Download-URL

バージョン 1.1 で追加.

バージョン 1.2 で非推奨: PEP 753 に従って、代わりに Project-URL (複数回の使用可) を使ってください。

そこからこのバージョンの配布物をダウンロードすることができる URL を含んだ文字列。 (これが意味するところは、 URL は何か ".../BeagleVote-latest.tgz" のようなものでは駄目で、 ".../BeagleVote-0.45.tgz" のようにバージョンを含むものでなければならないということです。)

要求事項

バージョン 1.1 で追加.

バージョン 1.2 で非推奨: Requires-Dist に従って

それぞれのエントリは、このパッケージが必要とする他のモジュールやパッケージを記述した文字列を含みます。

要求事項の文字列のフォーマットは、 import ステートメントで使うことができるモジュールやパッケージの名前のフォーマットと同一のもので、オプションとしてカッコ内に入れたバージョン宣言を伴うことがあります。

バージョン宣言は、一連の比較演算子とバージョン番号をカンマで区切ったものです。比較演算子は、"<", ">", "<=", ">=", "==", "!=" のいずれかひとつでなければなりません。バージョン番号は、 distutils.version.StrictVersion によって受け入れられるフォーマットでなければなりません: 二つか三つの数字部分をドットで区切ったもので、オプションとして 'a' か 'b' の後ろに数字が続く形の "pre-release" タグを末尾につけたもの。バージョン番号の例としては、 "1.0" や "2.3a2" や "1.3.99" 、

例えば ">1.0, !=1.3.4, <2.0" という文字列が正当なバージョン宣言であるように、比較演算子はいくつでも指定することができます。

次に示すすべての要求仕様文字列 <requirement strings> は実際に可能なものです: "rfc822", "zlib (>=1.1.4)", "zope"。

どのような文字列が用いられるべきであるかについては、公式に認められたリストはありません; 独自の標準を選択することが Python コミュニティに委ねられています。

例

Requires: re
Requires: sys
Requires: zlib
Requires: xml.parsers.expat (>1.0)
Requires: psycopg

提供する

バージョン 1.1 で追加.

バージョン 1.2 で非推奨: Provides-Dist を支持して <in favour of>

それぞれのエントリには、そのパッケージをインストールすると提供されるであろうパッケージなりモジュールなりについて記述した文字列を含みます。このような文字列は、Requirements フィールドで使われるものに合致しているべきです。 (比較演算子なしなら) バージョン宣言もあっても構いません; もしバージョン宣言がなければ、そのパッケージのバージョン番号を援用します。

例

Provides: xml
Provides: xml.utils
Provides: xml.utils.iso8601
Provides: xml.dom
Provides: xmltools (1.3)

古くなった <Obsoletes>

バージョン 1.1 で追加.

バージョン 1.2 で非推奨: Obsoletes-Dist に従って

それぞれのエントリには、あるパッケージなりモジュールなりがあることで、このパッケージが使われなくなっている <obsolete> ということを記述する、すなわち、これら二つのパッケージは同時にはインストールされるべきではないことを示す、そのような文字列が含まれます。バージョン宣言を書いておくことができます。

このフィールドの最もよくある使い方は、例えば Gorgon 2.3 が Torqued Python 1.0 の一部として組み込まれた時のように、プロジェクトの名前が変更された場合でしょう。 Torqued Python をインストールするなら、 Gorgon パッケージは削除されるべきです。

例:

Obsoletes: Gorgon

歴史

  • 2001年3月: PEP 241 を通じてコアとなるメタデータ 1.0 が承認されました。

  • 2003年4月: PEP 314 を通じてコアとなるメタデータ 1.1 が承認されました。

  • 2010年2月: PEP 345 を通じてコアとなるメタデータ 1.2 が承認されました。

  • 2018年2月: PEP 566 を通じてコアとなるメタデータ 2.1 が承認されました。

    • Description-Content-Type と Provides-Extra を追加しました。

    • メタデータを JSON に変換する正規化された方法を追加しました。

    • Name フィールドの文法に制限を加えました。

  • 2020年10月: PEP 643 を通じてコアとなるメタデータ 2.2 が承認されました。

    • Dynamic フィールドを追加しました。

  • 2022年3月: PEP 685 を通じてコアとなるメタデータ 2.3 が承認されました。

    • その他の名称 <extra names> の標準化に制限を加えました。

  • 2024年8月: PEP 639 を通じて、コアとなるメタデータ 2.4 が承認されました。

    • License-Expression フィールドを追加しました。

    • License-File フィールドを追加しました。

  • 2025年8月: 動的 <Dynamic> 指定がそのフィールドの取り扱いに影響を与えるのは、 sdist から wheel をビルドする時だけであって、 wheel を変換するするときには影響を与えないのだということが明確化された。

  • 2025年9月: PEP 794 を通じてコアとなるメタデータ 2.5 が承認されました。

    • Import-Name フィールドを追加しました。

    • Import-Namespace フィールドを追加しました。

  • 2025年10月: License-Expression は、含まれている配布物のファイルに適用されるのであって、プロジェクトそれ自体に適用されるものではないことを明確にした。

  • January 2026: Replaced outdated direct reference to PEP 508 with a reference to 依存関係指定子.