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

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

  • 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"。

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

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

例:

Metadata-Version: 2.3

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 ファイルでは異なる場合があることを示します。

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 はコンマで区切ります。これらのツールは多年に渡って非常に広く使われていますので、仕様をデファクト標準に合わせる形で更新する方が簡単でした。

Home-page#

バージョン 1.0 で追加.

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

例:

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

Download-URL#

バージョン 1.1 で追加.

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

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 で追加.

"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

Classifier (複数回の使用可)#

バージョン 1.1 で追加.

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

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

例:

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

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

バージョン 1.2 で追加.

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

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

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

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

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

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

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

許容されるフォーマットの詳細については PEP 508 を見てください。

プロジェクト名は、 Python パッケージインデックス に出現する名前に対応していなければなりません。

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

例:

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 文字以内のフリーテキストです。

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: に対する規則に照らして値が正当ではないとすればユーザは警告されるべきで、その値は曖昧さを避けるために無視されるべきです。古めのメタデータバージョンとして不当な名前を読み取った場合には、ツールはエラーを発出することを選択しても構いません。

稀に使われるフィールド#

この節のフィールドは、 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"

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

要求事項#

バージョン 1.1 で追加.

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

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

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

バージョン宣言は、一連の比較演算子とバージョン番号をカンマで区切ったものです。比較演算子は、"<", ">", "<=", ">=", "==", "!=" のいずれかひとつでなければなりません。バージョン番号は、オプションとして '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> の標準化に制限を加えました。