CPAN-Meta-2.132140 > CPAN::Meta::Spec
CPAN-Meta-2.132140
CPANで確認する
Source
編集

名前

CPAN::Meta::Spec - specification for CPAN distribution metadata

CPAN::Meta::Spec - CPAN ディストリビューションのメタデータ仕様

VERSION

version 2.132140

概要

  my $distmeta = {
    name => 'Module-Build',
    abstract => 'Build and install Perl modules',
    description =>  "Module::Build is a system for "
      . "building, testing, and installing Perl modules. "
      . "It is meant to ... blah blah blah ...",
    version  => '0.36',
    release_status => 'stable',
    author   => [
      'Ken Williams <[email protected]>',
      'Module-Build List <[email protected]>', # additional contact
    ],
    license  => [ 'perl_5' ],
    prereqs => {
      runtime => {
        requires => {
          'perl'   => '5.006',
          'ExtUtils::Install' => '0',
          'File::Basename' => '0',
          'File::Compare'  => '0',
          'IO::File'   => '0',
        },
        recommends => {
          'Archive::Tar' => '1.00',
          'ExtUtils::Install' => '0.3',
          'ExtUtils::ParseXS' => '2.02',
        },
      },
      build => {
        requires => {
          'Test::More' => '0',
        },
      }
    },
    resources => {
      license => ['http://dev.perl.org/licenses/'],
    },
    optional_features => {
      domination => {
        description => 'Take over the world',
        prereqs     => {
          develop => { requires => { 'Genius::Evil'     => '1.234' } },
          runtime => { requires => { 'Machine::Weather' => '2.0'   } },
        },
      },
    },
    dynamic_config => 1,
    keywords => [ qw/ toolchain cpan dual-life / ],
    'meta-spec' => {
      version => '2',
      url     => 'http://search.cpan.org/perldoc?CPAN::Meta::Spec',
    },
    generated_by => 'Module::Build version 0.36',
  };

説明

This document describes version 2 of the CPAN distribution metadata specification, also known as the "CPAN Meta Spec".

このドキュメントは、CPANディストリビューションメタデータ仕様のバージョン2について 書いています。"CPAN Meta Spec"とも知られています。

Revisions of this specification for typo corrections and prose clarifications may be issued as CPAN::Meta::Spec 2.x. These revisions will never change semantics or add or remove specified behavior.

typoの修正や散文的な説明のための、この仕様のリビジョンは、CPAN::Meta::Spec 2.x のようになります。これらのリビジョンは、セマンティクスの変更や追加、特定の振る舞いの削除 を行いません。

Distribution metadata describe important properties of Perl distributions. Distribution building tools like Module::Build, Module::Install, ExtUtils::MakeMaker or Dist::Zilla should create a metadata file in accordance with this specification and include it with the distribution for use by automated tools that index, examine, package or install Perl distributions.

ディストリビューションのメタデータはPerlのディストリビューションの重要な 必要条件を記述しています。Module::Build、Module::Install、ExtUtils::MakeMakerやDist::Zillaのような ディストリビューションをビルドするツールは、仕様に則ったメタデータファイルを作るべきであり、 ディストリビューション内に含めるべきです。インデックスや検査やパッケージ化、 Perlディストリビューションのインストールといった自動化されたツールをによって使われます。

用語

distribution

(ディストリビューション)

This is the primary object described by the metadata. In the context of this document it usually refers to a collection of modules, scripts, and/or documents that are distributed together for other developers to use. Examples of distributions are Class-Container, libwww-perl, or DBI.

メタデータによって記述される主要なのものです。このドキュメントの中では、 普通、モジュールやスクリプトおよび/または、他の開発者が使うために一緒に配布されるドキュメント の集合を言います。ディストリビューションの例としては、Class-Container、 libwww-perlや DBI です。

module

(モジュール)

This refers to a reusable library of code contained in a single file. Modules usually contain one or more packages and are often referred to by the name of a primary package that can be mapped to the file name. For example, one might refer to File::Spec instead of File/Spec.pm

1つのファイルに含まれた再利用可能なライブラリのコードのことです。 モジュールは、普通、１つ以上のパッケージを含み、ファイル名とマップできる メインのパッケージの名前で参照されます。例えば、File/Spec.pmの 代わりに、File::Specで参照する人もいます。

package

(パッケージ)

This refers to a namespace declared with the Perl package statement. In Perl, packages often have a version number property given by the $VERSION variable in the namespace.

Perlのpackage文で宣言された名前空間のことです。 Perlでは、パッケージは、たいてい、名前空間内の$VERSION変数で、バージョン番号のプロパティを 持っています。

consumer

(コンシューマ)

This refers to code that reads a metadata file, deserializes it into a data structure in memory, or interprets a data structure of metadata elements.

メタデータファイルを読むコードのことです。デシリアライズして、メモリ内で データ構造にするか、メタデータのデータ構造を解釈します。

producer

(プロデューサ)

This refers to code that constructs a metadata data structure, serializes into a bytestream and/or writes it to disk.

メタデータ構造を作るコードのことです。バイトストリームに シリアライズするか、または、ディスクにそれを書きます。

must, should, may, etc.

(必須、要請、可能、など)

These terms are interpreted as described in IETF RFC 2119.

これらの用語は、IETF RFC 2119 に書かれている用に解釈されます。

データ型

Fields in the "STRUCTURE" section describe data elements, each of which has an associated data type as described herein. There are four primitive types: Boolean, String, List and Map. Other types are subtypes of primitives and define compound data structures or define constraints on the values of a data element.

"構造"セクションで書かれているデータ要素のフィールドは、 そのそれぞれが、ここに書かれていあるようなデータ型に関連します。 4つのプリミティブな型があります: ブール、文字列、リスト、マップ。他の型は プリミティブな型のサブタイプであり、合成したデータ構造を定義するか、 データ要素の値で制約を定義します。

Boolean

A Boolean is used to provide a true or false value. It must be represented as a defined value.

ブール値 は、真か偽の値を提供するのに使われます。 定義された値として 表現されなければなりません。

String

A String is data element containing a non-zero length sequence of Unicode characters, such as an ordinary Perl scalar that is not a reference.

文字列はゼロ文字幅でない連続するユニコードキャラクタのデータです。 リファレンスでない、普通のPerlのスカラのようなデータです。

List

A List is an ordered collection of zero or more data elements. Elements of a List may be of mixed types.

リストは、0以上のデータ要素の順番のある集合です。 リストのエレメントは複数の型になってもよいです。

Producers must represent List elements using a data structure which unambiguously indicates that multiple values are possible, such as a reference to a Perl array (an "arrayref").

プロデューサは、Perlの配列へのリファレンス("arrayref")のように、複数の値が可能であることを はっきり示すデータ構想を使って、リストの要素を表現しなければいけません。

Consumers expecting a List must consider a String as equivalent to a List of length 1.

リストを期待するコンシューマは文字列を長さ1のリストに等しいと考えなければいけません。

Map

A Map is an unordered collection of zero or more data elements ("values"), indexed by associated String elements ("keys"). The Map's value elements may be of mixed types.

マップは0以上の順番のないデータ要素("値")の集合です。 関連する文字列の要素("キー")によってインデックスされます。 マップの値の要素は複数の型になってもよいです。

License String

A License String is a subtype of String with a restricted set of values. Valid values are described in detail in the description of the "license" field.

A ライセンス文字列は文字列のサブタイプで、値は制限されています。 有効な値は、"license"のフィールドの説明に詳しく書かれています。

URL

URL is a subtype of String containing a Uniform Resource Locator or Identifier. [ This type is called URL and not URI for historical reasons. ]

URLは文字列のサブタイプで、ユニフォームリソースロケータかアイデンティファイアです。 [このタイプはURLと呼ばれており、歴史的な理由でURIとは呼ばれません]

バージョン

A Version is a subtype of String containing a value that describes the version number of packages or distributions. Restrictions on format are described in detail in the "Version Formats" section.

バージョンは、文字列のサブタイプで、パッケージかディストリビューションの バージョン番号です。フォーマットに関する制限は"バージョンフォーマット"の セクションにあります。

バージョンの範囲

The Version Range type is a subtype of String. It describes a range of Versions that may be present or installed to fulfill prerequisites. It is specified in detail in the "Version Ranges" section.

バージョンの範囲型は文字列のサブタイプです。必要条件を満たすために、 存在するか、インストールされるバージョンの範囲を表します。 "バージョンの範囲"セクションで詳しく明記されています。

構造

The metadata structure is a data element of type Map. This section describes valid keys within the Map.

メタデータの構造はマップ型のデータ要素です。このセクションでは マップの有効なキーについて説明します。

Any keys not described in this specification document (whether top-level or within compound data structures described herein) are considered custom keys and must begin with an "x" or "X" and be followed by an underscore; i.e. they must match the pattern: qr{\Ax_}i. If a custom key refers to a compound data structure, subkeys within it do not need an "x_" or "X_" prefix.

この仕様書に書かれていないキー(トップレベルかここで説明される合成のデータ構造)は カスタムキーと考えられ、"x"か"X"で始まり、アンダースコアで続けられなければいけません; すなわち、qr{\Ax_}i のパターンにマッチしなければいけません。 カスタムキーが合成のデータ構造を参照していれば、そのサブキーには"x_"か"X_"のプレフィックス は不要です。

Consumers of metadata may ignore any or all custom keys. All other keys not described herein are invalid and should be ignored by consumers. Producers must not generate or output invalid keys.

メタデータのコンシューマはいずれかの、または、すべてのカスタムキーを無視してもよいです。 ここで説明されていないすべての他のキー不正であり、コンシューマによって無視されるべきです。 プロデューサは不正なキーを生成したり、出力してはいけません。

For each key, an example is provided followed by a description. The description begins with the version of spec in which the key was added or in which the definition was modified, whether the key is required or optional and the data type of the corresponding data element. These items are in parentheses, brackets and braces, respectively.

それぞれのキーごとに、説明の前に例があります。 説明はキーが加えれたバージョンか定義が変更されるたバージョン、 キーが必須かオプショナルかどうか、一致するデータ要素のデータ型で始まっています。 これらのアイテムは、それぞれ括弧、ブラケット、ブレス内にあります。

If a data type is a Map or Map subtype, valid subkeys will be described as well.

データ型がマップかマップのサブタイプであれば、有効なサブキーが説明されます。

Some fields are marked Deprecated. These are shown for historical context and must not be produced in or consumed from any metadata structure of version 2 or higher.

フィールドには、廃止されたものもあります。これらは歴史的な文脈で示されており、 バージョン2以上のメタデータ構造から、生成されても、読まれてもいけません。

必須フィールド

abstract

Example:

例:

  abstract => 'Build and install Perl modules'

(Spec 1.2) [required] {String}

This is a short description of the purpose of the distribution.

ディストリビューションの目的を簡単に説明するものです。

author

Example:

例:

  author => [ 'Ken Williams <[email protected]>' ]

(Spec 1.2) [required] {List of one or more Strings}

This List indicates the person(s) to contact concerning the distribution. The preferred form of the contact string is:

このリストは、ディストリビューションに関係する人(たち)の連絡先を示します。 連絡先の望ましい形式の文字列は:

  contact-name <email-address>

This field provides a general contact list independent of other structured fields provided within the "resources" field, such as bugtracker. The addressee(s) can be contacted for any purpose including but not limited to (security) problems with the distribution, questions about the distribution or bugs in the distribution.

このフィールドは、一般的なコンタクトリストを提供します。 他の構造のフィールド、"resouces"フィールドや、bugtrackerのようなフィールドとは 独立しています。ディストリビューションについての(セキュリティの)問題や、 ディストリビューションについての質問、ディストリビューションのバグに限定されない、 どのような目的のためにも、連絡可能なナアドレスです。

A distribution's original author is usually the contact listed within this field. Co-maintainers, successor maintainers or mailing lists devoted to the distribution may also be listed in addition to or instead of the original author.

ディストリビューションのオリジナルの作者が、普通はこのフィールドにのる連絡先です。 共同メンテナや、後継メンテナ、またはそのディストリビューションの熱心なメーリングリスが、 オリジナルの作者の代わりに、リストされてもよいです。

dynamic_config

Example:

例:

  dynamic_config => 1

(Spec 2) [required] {Boolean}

A boolean flag indicating whether a Build.PL or Makefile.PL (or similar) must be executed to determine prerequisites.

真偽値のフラグで、Build.PLかMakefile.PL(また、その仲間)が 必要条件を決定するために、実行されなければならないかどうかを示します。

This field should be set to a true value if the distribution performs some dynamic configuration (asking questions, sensing the environment, etc.) as part of its configuration. This field should be set to a false value to indicate that prerequisites included in metadata may be considered final and valid for static analysis.

このフィールドは、ディストリビューションが、設定の一部として 何かしら動的な設定(質問を尋ねる、環境を調べるなど)をするのであれば、 真の値にするべきです。このフィールドはメタデータに含まれる必要条件が 静的な分析にとって、最終かつ妥当だと考えてもよいのであれば、 偽にセットされるべきです。

This field explicitly does not indicate whether installation may be safely performed without using a Makefile or Build file, as there may be special files to install or custom installation targets (e.g. for dual-life modules that exist on CPAN as well as in the Perl core). This field only defines whether prerequisites are complete as given in the metadata.

このフィールドは、インストールに特別なファイルかカスタムインストレーションターゲット があるかもしれないとして(例えば、Perlコアと同様にCPANにも存在する デュアル・ライフモジュールのために)、インストールがMakefileやBuldファイルを使わずに 安全に実行されるかどうかを、明示的に示しません。 このフィールドは必要条件がメタデータに与えられているもので完全かどうかのみを決定します。

generated_by

Example:

例:

  generated_by => 'Module::Build version 0.36'

(Spec 1.0) [required] {String}

This field indicates the tool that was used to create this metadata. There are no defined semantics for this field, but it is traditional to use a string in the form "Generating::Package version 1.23" or the author's name, if the file was generated by hand.

このフィールドはこのメタデータを作るのに使われたツールを示します。 このフィールド用のセマンティクスは定義されていません。ですが、伝統的に、 "Generating::Package version 1.2.3" な形式の文字列として使うか、ファイルを 手で作ったのなら作者の名前を使います。

license

Example:

  license => [ 'perl_5' ]

  license => [ 'apache_2', 'mozilla_1_0' ]

(Spec 2) [required] {List of one or more License Strings}

One or more licenses that apply to some or all of the files in the distribution. If multiple licenses are listed, the distribution documentation should be consulted to clarify the interpretation of multiple licenses.

ディストリビューション内のいくつかかすべてのファイルに適用されている 1つ以上のライセンスです。複数のライセンスがリストされているなら、ディストリビューションの ドキュメントは複数のライセンスの説明を明確にすべきです。

The following list of license strings are valid:

下記のリストは有効なライセンス文字列のリストです:

 string          description
 -------------   -----------------------------------------------
 agpl_3          GNU Affero General Public License, Version 3
 apache_1_1      Apache Software License, Version 1.1
 apache_2_0      Apache License, Version 2.0
 artistic_1      Artistic License, (Version 1)
 artistic_2      Artistic License, Version 2.0
 bsd             BSD License (three-clause)
 freebsd         FreeBSD License (two-clause)
 gfdl_1_2        GNU Free Documentation License, Version 1.2
 gfdl_1_3        GNU Free Documentation License, Version 1.3
 gpl_1           GNU General Public License, Version 1
 gpl_2           GNU General Public License, Version 2
 gpl_3           GNU General Public License, Version 3
 lgpl_2_1        GNU Lesser General Public License, Version 2.1
 lgpl_3_0        GNU Lesser General Public License, Version 3.0
 mit             MIT (aka X11) License
 mozilla_1_0     Mozilla Public License, Version 1.0
 mozilla_1_1     Mozilla Public License, Version 1.1
 openssl         OpenSSL License
 perl_5          The Perl 5 License (Artistic 1 & GPL 1 or later)
 qpl_1_0         Q Public License, Version 1.0
 ssleay          Original SSLeay License
 sun             Sun Internet Standards Source License (SISSL)
 zlib            zlib License

The following license strings are also valid and indicate other licensing not described above:

以下のライセンス文字列も有効で、上記のリストにない他のライセンスを 示します:

 string          description
 -------------   -----------------------------------------------
 open_source     Other Open Source Initiative (OSI) approved license
 restricted      Requires special permission from copyright holder
 unrestricted    Not an OSI approved license, but not restricted
 unknown         License not provided in metadata

All other strings are invalid in the license field.

これら以外の文字列はライセンスのフィールドとして不正です。

meta-spec

Example:

例:

  'meta-spec' => {
    version => '2',
    url     => 'http://search.cpan.org/perldoc?CPAN::Meta::Spec',
  }

(Spec 1.2) [required] {Map}

This field indicates the version of the CPAN Meta Spec that should be used to interpret the metadata. Consumers must check this key as soon as possible and abort further metadata processing if the meta-spec version is not supported by the consumer.

このフィールドはCPANメタデータ仕様のバージョンを示しています。このフィールドは メターデータを解釈するのに使われるべきです。コンシューマはこのキーを 可能な限りはやくチェックしなければいけなませんし、コンシューマがその メタデータ仕様のバージョンをサポートしないなら、以降のメタデータの処理を 中止しなければいけません。

The following keys are valid, but only version is required.

以下のキーは有効ですが、versionのみが必須です。

version

This subkey gives the integer Version of the CPAN Meta Spec against which the document was generated.

このサブキーはドキュメントが生成された、CPANメタデータ仕様の 整数のバージョンです。

url

This is a URL of the metadata specification document corresponding to the given version. This is strictly for human-consumption and should not impact the interpretation of the document.

これは、与えられたバージョンに一致するメタデータ仕様のドキュメントのURLです。 これは完全に人間の消費のためのものであり、ドキュメントの解釈に影響を与えるべきではありません。

name

Example:

例:

  name => 'Module-Build'

(Spec 1.0) [required] {String}

This field is the name of the distribution. This is often created by taking the "main package" in the distribution and changing :: to -, but the name may be completely unrelated to the packages within the distribution. C.f. http://search.cpan.org/dist/libwww-perl/.

このフィールドはディストリビューションの名前です。これは、 ディストリビューションの"メインのパッケージ" から取られて、::を-に変換して、 作られることが多いです。ですが、名前はディストリビューション内のパッケージ とまったく関係なくてもよいです。 C.f. http://search.cpan.org/dist/libwww-perl/.

release_status

Example:

例:

  release_status => 'stable'

(Spec 2) [required] {String}

This field provides the release status of this distribution. If the version field contains an underscore character, then release_status must not be "stable."

このフィールドはディストリビューションのリリース状態を提供します。 versionフィールドがアンダースコアを含んでいる場合、 release_status を"stable"にしてはいけません。

The release_status field must have one of the following values:

release_status フィールドは、以下の値のいずれかでなければいけません:

stable

This indicates an ordinary, "final" release that should be indexed by PAUSE or other indexers.

これは、普通、PAUSEや他のインデックサによってインデックスされるべき "final"リリースを示します。

testing

This indicates a "beta" release that is substantially complete, but has an elevated risk of bugs and requires additional testing. The distribution should not be installed over a stable release without an explicit request or other confirmation from a user. This release status may also be used for "release candidate" versions of a distribution.

これは、大半は完成している"ベータ" リリースを示します。ですが、バグがあるリスクが高く、 追加のテストが必要な状態です。ディストリビューションは明確な要求やユーザーからの 確認なしに、stable リリースを超えてインストールすべきではありません。 このリリースステータスはディストリビューションの"リリース候補"のバージョンにも 使ってもよいです。

unstable

This indicates an "alpha" release that is under active development, but has been released for early feedback or testing and may be missing features or may have serious bugs. The distribution should not be installed over a stable release without an explicit request or other confirmation from a user.

これは、活発に開発中の"アルファ"リリースを示します。ですが、 早期のフィードバックやテストのためにリリースされており、 足りない機能や深刻なバグがあってもよいです。ディストリビューションは 明確な要求やユーザーからの確認なしに、stable リリースを超えて インストールすべきではありません。

Consumers may use this field to determine how to index the distribution for CPAN or other repositories in addition to or in replacement of heuristics based on version number or file name.

コンシューマは、CPANや他のリポジトリにどのようにインデックスするかを決定するのに、 バージョン番号やファイル名に基づいた経験則に加えて、または、その代わりに、 このフィールドを使ってもよいです。

version

Example:

例:

  version => '0.36'

(Spec 1.0) [required] {Version}

This field gives the version of the distribution to which the metadata structure refers.

このフィールドは、メタデータ構造が参照するディストリビューションのバージョン番号を 与えます。

オプションのフィールド

description

Example:

例:

    description =>  "Module::Build is a system for "
      . "building, testing, and installing Perl modules. "
      . "It is meant to ... blah blah blah ...",

(Spec 2) [optional] {String}

A longer, more complete description of the purpose or intended use of the distribution than the one provided by the abstract key.

abstractキーで提供されるよりも、より長い、より完全な、ディストリビューションの 目的や、意図する使い方の説明です。

keywords

Example:

例:

  keywords => [ qw/ toolchain cpan dual-life / ]

(Spec 1.1) [optional] {List of zero or more Strings}

A List of keywords that describe this distribution. Keywords must not include whitespace.

ディストリビューションを説明するキーワードのリストです。キーワードは 空白を含んではいけません。

no_index

Example:

例:

  no_index => {
    file      => [ 'My/Module.pm' ],
    directory => [ 'My/Private' ],
    package   => [ 'My::Module::Secret' ],
    namespace => [ 'My::Module::Sample' ],
  }

(Spec 1.2) [optional] {Map}

This Map describes any files, directories, packages, and namespaces that are private to the packaging or implementation of the distribution and should be ignored by indexing or search tools.

このマップは、ディストリビューションのパッケージングや実装で、プライベートであり、 検索ツールやインデックスによって無視されるべき、ファイル、ディレクトリ、パッケージ、 名前空間を記述します。

Valid subkeys are as follows:

正しいサブキーは以下のものです:

file

A List of relative paths to files. Paths must be specified with unix conventions.

相対パスのファイルのリストです。パスは unix の書き方で指定 されなければいけません。

directory

A List of relative paths to directories. Paths must be specified with unix conventions.

相対パスのディレクトリのリストです。パスは unix の書き方で指定 されなければいけません。

[ Note: previous editions of the spec had dir instead of directory ]

[ 注意: 以前のバージョンでは、directoryの代わりにdirでした ]

package

A List of package names.

パッケージ名のリスト。

namespace

A List of package namespaces, where anything below the namespace must be ignored, but not the namespace itself.

名前空間のリストで、その名前空間以降はどこでも無視されなければいけません。 ですが、名前空間それ自身は無視されるべきではありません。

In the example above for no_index, My::Module::Sample::Foo would be ignored, but My::Module::Sample would not.

上の例にある no_index の場合、My::Module::Sample::Fooは 無視されますが、My::Module::Sampleは無視されません。

optional_features

Example:

例:

  optional_features => {
    sqlite => {
      description => 'Provides SQLite support',
      prereqs => {
        runtime => {
          requires => {
            'DBD::SQLite' => '1.25'
          }
        }
      }
    }
  }

(Spec 2) [optional] {Map}

This Map describes optional features with incremental prerequisites. Each key of the optional_features Map is a String used to identify the feature and each value is a Map with additional information about the feature. Valid subkeys include:

このマップは、インクリメンタルな必要条件に関するオプションの機能です。 optional_featuresマップののそれそれのキーは機能と一致させるのに使われる 文字列であり、それぞれの値は機能に関する追加の情報のマップです。 正しいサブキーは:

description

This is a String describing the feature. Every optional feature should provide a description

機能を記述する文字列です。すべてのオプションの機能は説明を 提供すべきです。

prereqs

This entry is required and has the same structure as that of the "prereqs" key. It provides a list of package requirements that must be satisfied for the feature to be supported or enabled.

このエントリーは必須で、"prereqs"キーと同じ構造です。 サポートする、または、利用可能な機能に対して、満さなければならない パッケージの要求のリストです。

There is one crucial restriction: the prereqs of an optional feature must not include configure phase prereqs.

重要な制限が1つあります: オプションの機能の必要条件は configureフェーズの必要条件を含んではいけません。

Consumers must not include optional features as prerequisites without explicit instruction from users (whether via interactive prompting, a function parameter or a configuration value, etc. ).

コンシューマは、ユーザーからの明確な指示なしに (インタラクティブなプロンプトか関数パラメータか、設定値など)、 必要条件としてオプションの機能を含んではいけません。

If an optional feature is used by a consumer to add additional prerequisites, the consumer should merge the optional feature prerequisites into those given by the prereqs key using the same semantics. See "Merging and Resolving Prerequisites" for details on merging prerequisites.

オプションの機能が、追加の必要条件を追加するためにコンシューマによって使われたら、 コンシューマはオプションの機能の必要条件を、同じセマンティクスを使っている prereqaキーで与えられている必要条件にマージすべきです。 必要条件のマージについての詳細は、"必要条件のマージと解決"を見てください。

Suggestion for disuse: Because there is currently no way for a distribution to specify a dependency on an optional feature of another dependency, the use of optional_feature is discouraged. Instead, create a separate, installable distribution that ensures the desired feature is available. For example, if Foo::Bar has a Baz feature, release a separate Foo-Bar-Baz distribution that satisfies requirements for the feature.

使わないことをおすすめ: 現在のところ、ディストリビューションが 他の依存のオプションの機能の依存を指定する方法がないので、 optional_featureの使用は推奨されません。その代わりに、 望ましい機能が利用できる、別の、インストールできるディストリビューション を作ります。例えば、Foo::BarにBaz機能があれば、 その機能のための要求を満たす、別のFoo-Bar-Bazディストリビューションを リリースします。

prereqs

Example:

例:

  prereqs => {
    runtime => {
      requires => {
        'perl'          => '5.006',
        'File::Spec'    => '0.86',
        'JSON'          => '2.16',
      },
      recommends => {
        'JSON::XS'      => '2.26',
      },
      suggests => {
        'Archive::Tar'  => '0',
      },
    },
    build => {
      requires => {
        'Alien::SDL'    => '1.00',
      },
    },
    test => {
      recommends => {
        'Test::Deep'    => '0.10',
      },
    }
  }

(Spec 2) [optional] {Map}

This is a Map that describes all the prerequisites of the distribution. The keys are phases of activity, such as configure, build, test or runtime. Values are Maps in which the keys name the type of prerequisite relationship such as requires, recommends, or suggests and the value provides a set of prerequisite relations. The set of relations must be specified as a Map of package names to version ranges.

このマップはディストリビューションのすべての必要条件を記述しています。 キーはアクティビティのフェーズであり、configure、build、test、 runtimeのようになります。値は、マップで、キーの名前は必要条件の関係性のタイプです。 requires、recommends、suggestsのようになり、その値は、必要条件の 関係のセットを提供します。 関係のセットはパッケージ名にバージョンの範囲のマップとして指定されなければいけません。

The full definition for this field is given in the "Prereq Spec" section.

このフィールドの完全な定義は"Prereq仕様"のセクションにあります。

provides

Example:

例:

  provides => {
    'Foo::Bar' => {
      file    => 'lib/Foo/Bar.pm',
      version => '0.27_02',
    },
    'Foo::Bar::Blah' => {
      file    => 'lib/Foo/Bar/Blah.pm',
    },
    'Foo::Bar::Baz' => {
      file    => 'lib/Foo/Bar/Baz.pm',
      version => '0.3',
    },
  }

(Spec 1.2) [optional] {Map}

This describes all packages provided by this distribution. This information is used by distribution and automation mechanisms like PAUSE, CPAN, and search.cpan.org to build indexes saying in which distribution various packages can be found.

これは、ディストリビューションによって提供されるすべてのパッケージを記述します。 この情報は、ディストリビューションと、PAUSE、CPAN、search.cpan.org のような自動メカニズムによって使われ、パッケージ内で見つけられる様々なパッケージの インデックスを作ります。

The keys of provides are package names that can be found within the distribution. If a package name key is provided, it must have a Map with the following valid subkeys:

providesのキーは、ディストリビューション内で見つけられる パッケージ名です。パッケージ名のキーが提供されたら、 以下のような正しいサブキーを持ったマップがなければいけません:

file

This field is required. It must contain a Unix-style relative file path from the root of the distribution directory to a file that contains or generates the package.

このフィールドは必須です。ディストリビューションのディレクトリのルートからの パッケージを含むか生成するファイルへのUnixスタイルの相対ファイルパスを含まなければ いけません。

version

If it exists, this field must contains a Version String for the package. If the package does not have a $VERSION, this field must be omitted.

これがあるなら、このフィールドはバージョン文字列をパッケージに 含まなければいけません。パッケージに$VERSIONがないなら、 このフィールドは省略しなければいけません。

resources

Example:

例:

  resources => {
    license     => [ 'http://dev.perl.org/licenses/' ],
    homepage    => 'http://sourceforge.net/projects/module-build',
    bugtracker  => {
      web    => 'http://rt.cpan.org/Public/Dist/Display.html?Name=CPAN-Meta',
      mailto => '[email protected]',
    },
    repository  => {
      url  => 'git://github.com/dagolden/cpan-meta.git',
      web  => 'http://github.com/dagolden/cpan-meta',
      type => 'git',
    },
    x_twitter   => 'http://twitter.com/cpan_linked/',
  }

(Spec 2) [optional] {Map}

This field describes resources related to this distribution.

このフィールドは、ディストリビューションに関係するリソースを記述します。

Valid subkeys include:

正しいサブキーは:

homepage

The official home of this project on the web.

web上のプロジェクトの公式のホーム。

license

A List of URL's that relate to this distribution's license. As with the top-level license field, distribution documentation should be consulted to clarify the interpretation of multiple licenses provided here.

ディストリビューションのライセンスに関係する、URLのリスト。 トップレベルのlicenseフィールでと同様、ディストリビューションのドキュメントは ここで提供される複数のライセンスの説明を明確にすべきです。

bugtracker

This entry describes the bug tracking system for this distribution. It is a Map with the following valid keys:

このエントリーはこのディストリビューションのバグトラッキングシステムを記述します。 下記の有効なキーを持つマップです。

  web    - a URL pointing to a web front-end for the bug tracker
  mailto - an email address to which bugs can be sent
repository

This entry describes the source control repository for this distribution. It is a Map with the following valid keys:

このエントリーはこのでディストリビューションのソースコントロールリポジトリを記述します。 以下の有効なキーを持つマップです。

  url  - a URL pointing to the repository itself
  web  - a URL pointing to a web front-end for the repository
  type - a lowercase string indicating the VCS used

Because a url like http://myrepo.example.com/ is ambiguous as to type, producers should provide a type whenever a url key is given. The type field should be the name of the most common program used to work with the repository, e.g. git, svn, cvs, darcs, bzr or hg.

http://myrepo.example.com/のようなURLは型として曖昧なので、 プロデューサはurlキーがあたえられたらいつでも、typeを提供するべきです。 typeフィールドは、リポジトリを操作する一般的なプログラムの名前であるべきです。 e.g. git, svn, cvs, darcs, bzr や hg。

廃止されたフィールド

build_requires

(Deprecated in Spec 2) [optional] {String}

Replaced by prereqs

prereqsで置き換えられました。

configure_requires

(Deprecated in Spec 2) [optional] {String}

Replaced by prereqs

prereqsで置き換えられました。

conflicts

(Deprecated in Spec 2) [optional] {String}

Replaced by prereqs

prereqsで置き換えられました。

distribution_type

(Deprecated in Spec 2) [optional] {String}

This field indicated 'module' or 'script' but was considered meaningless, since many distributions are hybrids of several kinds of things.

このフィールドは、'module' か 'script' を指定しますが、多くのディストリビューションは、 複数の種類のもののハイブリッドなため、意味がないと考えられました。

license_uri

(Deprecated in Spec 1.2) [optional] {URL}

Replaced by license in resources

resources内のlicenseで置き換えられました。

private

(Deprecated in Spec 1.2) [optional] {Map}

This field has been renamed to "no_index".

このフィールドは、"no_index"にリネームされました。

recommends

(Deprecated in Spec 2) [optional] {String}

Replaced by prereqs

prereqsで置き換えられました。

requires

(Deprecated in Spec 2) [optional] {String}

Replaced by prereqs

prereqsで置き換えられました。

バージョン番号

バージョンフォーマット

This section defines the Version type, used by several fields in the CPAN Meta Spec.

このセクションではバージョン型を定義します。CPANメタデータ仕様のいくつかのフィールドで 使われています。

Version numbers must be treated as strings, not numbers. For example, 1.200 must not be serialized as 1.2. Version comparison should be delegated to the Perl version module, version 0.80 or newer.

バージョン番号は、文字列として扱われなければならず、番号ではありません。 例として、1.200は、1.2としてシリアライズされなければいけません。 バージョンの比較は、Perlのvesionモジュールの0.8以上に委譲されるべきです。

Unless otherwise specified, version numbers must appear in one of two formats:

特記のない限り、バージョン番号は2つのうちのいずれかのフォーマットで なければいけません。

少数のバージョン

Decimal versions are regular "decimal numbers", with some limitations. They must be non-negative and must begin and end with a digit. A single underscore may be included, but must be between two digits. They must not use exponential notation ("1.23e-2").

少数のバージョンは定まった、いくつかの制限のある"少数"です。 プラスでなければいけませんし、数字で始まり、数字で終わらなければいけません 1つのアンダースコアは含まれていてもよいですが、2つの数字の間でなければいけません。 指数表記の("1.23e-2")を使ってはいけません。

   version => '1.234'       # OK
   version => '1.23_04'     # OK

   version => '1.23_04_05'  # Illegal
   version => '1.'          # Illegal
   version => '.1'          # Illegal
ドットで括られた整数のバージョン

Dotted-integer (also known as dotted-decimal) versions consist of positive integers separated by full stop characters (i.e. "dots", "periods" or "decimal points"). This are equivalent in format to Perl "v-strings", with some additional restrictions on form. They must be given in "normal" form, which has a leading "v" character and at least three integer components. To retain a one-to-one mapping with decimal versions, all components after the first should be restricted to the range 0 to 999. The final component may be separated by an underscore character instead of a period.

Dotted-integer(または、dotted-decimal)のバージョンは正の整数が、 句点文字("ドット"、"ピリオド"、"少数点")で区切られた構成です。 これは、いくつかの追加の制限の付いたPerlの"v-strings"フォーマットと同じです。 それらは、"v"文字に続いて、少なくとも3つの整数を含んだ、 "普通"の形で与えられなければなりません。 少数バージョンとの1対1のマッピングを保つために、最初の後のすべてのものは、 0から999の間に制限されるべきです。 最後のものは、ピリオドの代わりにアンダースコア文字で分けられてもよいです。

   version => 'v1.2.3'      # OK
   version => 'v1.2_3'      # OK
   version => 'v1.2.3.4'    # OK
   version => 'v1.2.3_4'    # OK
   version => 'v2009.10.31' # OK

   version => 'v1.2'          # Illegal
   version => '1.2.3'         # Illegal
   version => 'v1.2_3_4'      # Illegal
   version => 'v1.2009.10.31' # Not recommended

バージョンの範囲

Some fields (prereq, optional_features) indicate the particular version(s) of some other module that may be required as a prerequisite. This section details the Version Range type used to provide this information.

いくつかのフィールド(prereq, optional_features)には、必要条件として必要とされる かもしれない他のモジュールの特定のバージョンを示します。 このセクションでは、この情報を提供するのに使われるバージョンの範囲の型を詳しく 述べます。

The simplest format for a Version Range is just the version number itself, e.g. 2.4. This means that at least version 2.4 must be present. To indicate that any version of a prerequisite is okay, even if the prerequisite doesn't define a version at all, use the version 0.

バージョンの範囲のもっとも単純なフォーマットはバージョン番号自身です。 例えば2.4のような。これは、少なくともバージョン2.4が存在しなければならない ことを意味します。必要条件のどのバージョンでも良いことを示すためには、 必要条件がバージョンをまったく定義していなくても、バージョン0を使います。

Alternatively, a version range may use the operators < (less than), <= (less than or equal), > (greater than), >= (greater than or equal), == (equal), and != (not equal). For example, the specification < 2.0 means that any version of the prerequisite less than 2.0 is suitable.

代わりに、バージョンの範囲は、<(未満)、<=(以上)、>(より上)、>=(以上)、 ==(等しい)、!=(等しくない)を使ってもよいです。例えば、 < 2.0は、2.0未満の必要条件のバージョンが適します。

For more complicated situations, version specifications may be AND-ed together using commas. The specification >= 1.2, != 1.5, < 2.0 indicates a version that must be at least 1.2, less than 2.0, and not equal to 1.5.

より複雑な状況のために、バージョンはカンマを使って、AND条件で指定できます。 >= 1.2, != 1.5, < 2.0の指定は、バージョンが少なくとも1.2、2.0未満 で、1.5ではないバージョンでなければいけないことを示します。

必要条件

Prereq仕様

The prereqs key in the top-level metadata and within optional_features define the relationship between a distribution and other packages. The prereq spec structure is a hierarchical data structure which divides prerequisites into Phases of activity in the installation process and Relationships that indicate how prerequisites should be resolved.

メタデータのトップレベルのと optional_features内のprereqsキーは、 ディストリビューションと他のパッケージの間の関係を定義します。 prereqの仕様の構造はインストールプロセスのアクティビティのフェーズと どのように必要条件が解決されるべきかを示す関係性に 必要条件を分けている階層データ構造です。

For example, to specify that Data::Dumper is required during the test phase, this entry would appear in the distribution metadata:

例えば、Data::Dumperはtestフェーズで必須であると指定するなら、 このエントリーはディストリビューションのメタデータで次のようになります:

  prereqs => {
    test => {
      requires => {
        'Data::Dumper' => '2.00'
      }
    }
  }

フェーズ

Requirements for regular use must be listed in the runtime phase. Other requirements should be listed in the earliest stage in which they are required and consumers must accumulate and satisfy requirements across phases before executing the activity. For example, build requirements must also be available during the test phase.

正規の使い方の要求はruntimeフェーズでリストされなければいけません。 他の要求は、必要とされるもっとも早い段階でリストされるべきです。 コンシューマはアクティビティが実行される前にフェーズをまたがって 要求を集めなければならないし、満たさなければいけません。例えば、 buildの要求はtestフェーズの間にも有効でなければいけません。

  before action       requirements that must be met
  ----------------    --------------------------------
  perl Build.PL       configure
  perl Makefile.PL

  make                configure, runtime, build
  Build

  make test           configure, runtime, build, test
  Build test

Consumers that install the distribution must ensure that runtime requirements are also installed and may install dependencies from other phases.

ディストリビューションをインストールするコンシューマは runtime要求もまたインストールされることを保証しなければ なりません。そして、他のフェーズから依存をインストールしてもよいです。

  after action        requirements that must be met
  ----------------    --------------------------------
  make install        runtime
  Build install
configure

The configure phase occurs before any dynamic configuration has been attempted. Libraries required by the configure phase must be available for use before the distribution building tool has been executed.

configure フェーズはどのような動的なコンフィギュレーションも試みられる前に 起こります。configureフェーズで必要とされるライブラリは、ディストリビューションの ビルドツールが実行される前に、使えなければいけません。

build

The build phase is when the distribution's source code is compiled (if necessary) and otherwise made ready for installation.

build フェーズは、ディストリビューションのソースコードがコンパイルされ(必要なら)、 インストールの準備ができた時です。

test

The test phase is when the distribution's automated test suite is run. Any library that is needed only for testing and not for subsequent use should be listed here.

test フェーズはディストリビューションの自動テストケースが走る時です。 テストにのみ必要で、その後の使用に必要でないライブラリはここでリストされる べきです。

runtime

The runtime phase refers not only to when the distribution's contents are installed, but also to its continued use. Any library that is a prerequisite for regular use of this distribution should be indicated here.

runtime フェーズは、ディストリビューションの内容がインストールされる時にのみ参照 されるだけでなく、継続的な使用時にも参照されます。ディストリビューションの正規の 使い方で必要条件となっているどのようなライブラリも、ここで示されるべきです。

develop

The develop phase's prereqs are libraries needed to work on the distribution's source code as its author does. These tools might be needed to build a release tarball, to run author-only tests, or to perform other tasks related to developing new versions of the distribution.

develop フェーズの prereqs はディストリビューションのソースコードを、 その作者が行うように利用するために必要なライブラリです。それらのツールは リリースするtarボールをビルドするのに必要かもしれないし、作者のみのテストを 実行するのに必要かもしれませんし、そのディストリビューションの新しいバージョン を開発するのに関連した他のタスクをするのに必要かもしれません。

関連

requires

These dependencies must be installed for proper completion of the phase.

この依存はフェーズを適切に完遂するためにインストールされなければいけません。

recommends

Recommended dependencies are strongly encouraged and should be satisfied except in resource constrained environments.

推奨される依存は、リソースが限られた環境でなけれは、強く推められ、 満たされるべきです。

suggests

These dependencies are optional, but are suggested for enhanced operation of the described distribution.

これらの依存はオプションですが、ディストリビューションの、いっそう良い操作のために 提案されます。

conflicts

These libraries cannot be installed when the phase is in operation. This is a very rare situation, and the conflicts relationship should be used with great caution, or not at all.

これらのライブラリはフェーズが実行中にインストールされえません。 とても稀なシチュエーションであり、conflictsの関係はかなり注意して使われるか、 まったく使わないべきです。

必要条件のマージと解決

Whenever metadata consumers merge prerequisites, either from different phases or from optional_features, they should merged in a way which preserves the intended semantics of the prerequisite structure. Generally, this means concatenating the version specifications using commas, as described in the "Version Ranges" section.

メタデータのコンシューマが違うフェーズからか、optional_featuresからのどちらかの 必要条件をマージするときはいつでも、必要条件の構造の意図されたセマンティクスを保存 するやり方でマージするべきです。一般的に、 これは、バージョンの範囲のセクションで書いたように、コンマを使ったバージョン指定で 結びつけることを意味します。

Another subtle error that can occur in resolving prerequisites comes from the way that modules in prerequisites are indexed to distribution files on CPAN. When a module is deleted from a distribution, prerequisites calling for that module could indicate an older distribution should be installed, potentially overwriting files from a newer distribution.

必要条件を解決する際に起きうる、他の微妙なエラーは、必要条件にあるモジュールが CPANでディストリビューションファイルにインデックスされる方法によります。 モジュールがディストリビューションから削除される時、そのモジュールのために呼ばれる 必要条件は、より古いバージョンがインストールされるべきであると指示し、 潜在的に、より新しいディストリビューションからファイルを上書きします。

For example, as of Oct 31, 2009, the CPAN index file contained these module-distribution mappings:

例えば、2009/10/31 として、CPANのインデックスファイルが、これらのモジュール- ディストリビューションのマッピングを含んでいたとして:

  Class::MOP                   0.94  D/DR/DROLSKY/Class-MOP-0.94.tar.gz
  Class::MOP::Class            0.94  D/DR/DROLSKY/Class-MOP-0.94.tar.gz
  Class::MOP::Class::Immutable 0.04  S/ST/STEVAN/Class-MOP-0.36.tar.gz

Consider the case where "Class::MOP" 0.94 is installed. If a distribution specified "Class::MOP::Class::Immutable" as a prerequisite, it could result in Class-MOP-0.36.tar.gz being installed, overwriting any files from Class-MOP-0.94.tar.gz.

"Class::MOP" 0.94がインストールされているとして考えると、ディストリビューションが "Class::MOP::Class::Imutable"を必要条件として指定していた場合、 Class-MOP-0.36.tar.gz がインストールされ、Class-MOP-0.93.tar.gz の すべてのファイルがオーバーライトされる結果になりえます。

Consumers of metadata should test whether prerequisites would result in installed module files being "downgraded" to an older version and may warn users or ignore the prerequisite that would cause such a result.

メタデータのコンシューマは、必要条件によって、インストールされているモジュールのファイルが より古いバージョンに"ダウングレード"される結果になるかどうかテストすべきです。 そして、ユーザーに警告してもよいし、そのような結果を引き起こす必要条件は無視 してもよいです。

シリアライゼーション

Distribution metadata should be serialized (as a hashref) as JSON-encoded data and packaged with distributions as the file META.json.

ディストリビューションのメタデータは(ハッシュリファレンスとして)JSONにエンコードされたデータに シリアライズされ、そのファイルはMETA.jsonとして、ディストリビューションに パッケージされるべきです。

In the past, the distribution metadata structure had been packed with distributions as META.yml, a file in the YAML Tiny format (for which, see YAML::Tiny). Tools that consume distribution metadata from disk should be capable of loading META.yml, but should prefer META.json if both are found.

過去に、ディストリビューションのメタデータの構造はMETA.ymlとしてディストリビューションに 同梱されていました。YAMLの小さいフォーマット(YAML::Tiny参照)のファイルです。 ディスクからディストリビューションのメタデータを使うツールは、 META.ymlをロードできるようにすべきですが、2つが見つかった場合は、META.jsonを 優先すべきです。

実装者向けの注意

Perlモジュールからバージョン番号を取り出す

To get the version number from a Perl module, consumers should use the MM->parse_version($file) method provided by ExtUtils::MakeMaker or Module::Metadata. For example, for the module given by $mod, the version may be retrieved in one of the following ways:

Perlモジュールからバージョン番号を取り出すには、コンシューマは ExtUtils::MakeMaker か Module::Metadataの MM->parse_version($file) メソッドを使うべきです。例えば、 $modで与えられるモジュールの場合、、バージョンは以下の方法の いずれかで取り出せます:

  # via ExtUtils::MakeMaker
  my $file = MM->_installed_file_for_module($mod);
  my $version = MM->parse_version($file)

The private _installed_file_for_module method may be replaced with other methods for locating a module in @INC.

プライベートの_installed_file_for_moduleメソッドを @INCに位置するモジュールのために、他のメソッドで置き換えてもよいです。

  # via Module::Metadata
  my $info = Module::Metadata->new_from_module($mod);
  my $version = $info->version;

If only a filename is available, the following approach may be used:

ファイル名のみが利用可能であれば、以下のアプローチを使ってもよいです:

  # via Module::Build
  my $info = Module::Metadata->new_from_file($file);
  my $version = $info->version;

バージョン番号の比較

The version module provides the most reliable way to compare version numbers in all the various ways they might be provided or might exist within modules. Given two strings containing version numbers, $v1 and $v2, they should be converted to version objects before using ordinary comparison operators. For example:

versionモジュールは、すべての様々な方法で提供されるか、モジュール内に存在するかもしれない、 バージョン番号を比較する、もっとも信頼できる方法を提供します。 バージョン番号を含む2つの文字列$v1と$v2があるとして、比較の操作の前に、 これらはversionオブジェクトに変換されるべきです。例えば:

  use version;
  if ( version->new($v1) <=> version->new($v2) ) {
    print "Versions are not equal\n";
  }

If the only comparison needed is whether an installed module is of a sufficiently high version, a direct test may be done using the string form of eval and the use function. For example, for module $mod and version prerequisite $prereq:

必要な比較が、インストールされているモジュールが十分に高いバージョンかどうかだけであれば、 直接のテストを文字列を使って、evalとuse関数の方法で出来ます。 例えば、モジュール$modと必要条件のバージョンの$prereqのテストは:

  if ( eval "use $mod $prereq (); 1" ) {
    print "Module $mod version is OK.\n";
  }

If the values of $mod and $prereq have not been scrubbed, however, this presents security implications.

ですが、$modと$prereqの値が汚染されていれば、この方法はセキュリティに影響 があります。

SEE ALSO

CPAN, http://www.cpan.org/

CPAN.pm, http://search.cpan.org/dist/CPAN/

CPANPLUS, http://search.cpan.org/dist/CPANPLUS/

ExtUtils::MakeMaker, http://search.cpan.org/dist/ExtUtils-MakeMaker/

Module::Build, http://search.cpan.org/dist/Module-Build/

Module::Install, http://search.cpan.org/dist/Module-Install/

JSON, http://json.org/

YAML, http://www.yaml.org/

CONTRIBUTORS

Ken Williams wrote the original CPAN Meta Spec (also known as the "META.yml spec") in 2003 and maintained it through several revisions with input from various members of the community. In 2005, Randy Sims redrafted it from HTML to POD for the version 1.2 release. Ken continued to maintain the spec through version 1.4.

Ken Williams がオリジナルのCPANメタデータ仕様("META.yml spec"としても知られる)を 2003年に書き、コミュニティの様々なメンバーからのインプットで、いくつかのリビジョンを メンテナンスしました。2005年に、Randy Sims がバージョン1.2のリリースのために HTMLからPODに書き直しました。Ken はバージョン1.4までメンテナンスを続けました。

In late 2009, David Golden organized the version 2 proposal review process. David and Ricardo Signes drafted the final version 2 spec in April 2010 based on the version 1.4 spec and patches contributed during the proposal process.

2009年の後半に、David Golden がバージョン2のプロポーザルレビュープロセスを 組織しました。David と Richardo Signes は、最終のバージョン2の仕様を 20010年の4月に、バージョン1.4の仕様をもとに下書きしました。 複数のパッチがプロポーザルプロセスの間、貢献しました。

Several others have contributed patches over the years. The full list of contributors in the repository history currently includes:

複数の人が数年に渡りパッチを貢献し続けました。現在、リポジトリの歴史にある、 貢献者のすべてのリストは以下の人々を含んでいます:

  2shortplanks
  Avar Arnfjord Bjarmason
  Christopher J. Madsen
  Damyan Ivanov
  David Golden
  Eric Wilhelm
  Ken Williams
  Lars DIECKOW
  Michael G. Schwern
  Randy Sims
  Ricardo Signes

作者

コピーライト & ライセンス

This software is copyright (c) 2010 by David Golden and Ricardo Signes.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.

Powered by Amon2, 翻訳, サイト. Operated by Japan Perl Association