| Use Case | Field / Command | Description |
|---|---|---|
| π Define distribution name | name: My-Dist | Required string; usual form is main module with :: replaced by -. |
| π’ Specify version | version: 1.23 | Distribution version number. |
| π Short summary | abstract: A module that does X | Required short description of the distribution. |
| π€ Author info | author: | Sequence of author strings; preferred: Author Name <email> |
| βοΈ License | license: perl | Required; one of: perl, gpl, artistic, apache, bsd, mit, lgpl, mozilla, open_source, restrictive, unrestricted. |
| π¦ Runtime prerequisites | requires: | Modules required for normal operation. |
| π§ Build prerequisites | build_requires: | Modules needed only for building/testing. |
| π§Ή Hide private files | no_index: | Exclude files/dirs/namespaces from search indexes. |
| π Dynamic configuration | dynamic_config: 0 | Set to 1 if Build.PL/Makefile.PL requires interactive input. |
| π― Optional features | optional_features: | Define feature groups that depend on extra modules. |
| π Resources | resources: | Links: homepage, license, bugtracker, repository, etc. |
--- #YAML:1.0
name: Module-Build
abstract: Build and install Perl modules
version: 0.20
author:
- Ken Williams <kwilliams AT cpan.org>
license: perl
distribution_type: module
requires:
Config: 0
Cwd: 0
Data::Dumper: 0
ExtUtils::Install: 0
File::Basename: 0
File::Compare: 0
File::Copy: 0
File::Find: 0
File::Path: 0
File::Spec: 0
IO::File: 0
perl: 5.005_03
recommends:
Archive::Tar: 1.00
ExtUtils::Install: 0.3
ExtUtils::ParseXS: 2.02
Pod::Text: 0
YAML: 0.35
build_requires:
Test: 0
resources:
license: http://dev.perl.org/licenses/
meta-spec:
version: 1.4
url: http://module-build.sourceforge.net/META-spec-v1.3.html
generated_by: Module::Build version 0.20
distribution β This is the primary object described by the META.yml specification. 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.
module β This refers to a reusable library of code typically contained in a single file. Currently,
we primarily talk of perl modules, but this specification should be open enough to apply to
other languages as well (ex. python, ruby). Examples of modules are Class::Container,
LWP::Simple, or DBD::File.
--- #YAML:1.0.
Example:
meta-spec:
version: 1.4
url: http://module-build.sourceforge.net/META-spec-v1.3.html
(Spec 1.1) [required] {URL} This field indicates the location of the version of the META.yml specification used.
Example:
name: Module-Build
(Spec 1.0) [required] {string} The name of the distribution which is often created by taking the "main module" in the distribution and changing "::" to "-". Sometimes it's completely different, however, as in the case of the libwww-perl distribution (see <http://search.cpan.org/dist/libwww-perl/>).
Example:
version: 0.20
(Spec 1.0) [required] {version} The version of the distribution to which the META.yml file refers.
Example:
abstract: Build and install Perl modules.
(Spec 1.1) [required] {string} A short description of the purpose of the distribution.
Example:
author:
- Ken Williams <kwilliams AT cpan.org>
(Spec 1.1) [required] {list of strings} A YAML sequence indicating the author(s) of the distribution. The preferred form is author-name <email-address>.
Example:
license: perl
(Spec 1.0) [required] {string} The license under which this distribution may be used and redistributed.
Must be one of the following licenses:
apache β The distribution is licensed under the Apache Software License version 1.1
(<http://opensource.org/licenses/Apache-1.1>).artistic β The distribution is licensed under the Artistic License version 1, as specified by the
Artistic file in the standard perl distribution
(<http://opensource.org/licenses/Artistic-Perl-1.0>).bsd β The distribution is licensed under the BSD 3βClause License
(<http://opensource.org/licenses/BSD-3-Clause>).gpl β The distribution is distributed under the terms of the GNU General Public License version 2
(<http://opensource.org/licenses/GPL-2.0>).lgpl β The distribution is distributed under the terms of the GNU Lesser General Public License
version 2 (<http://opensource.org/licenses/LGPL-2.1>).mit β The distribution is licensed under the MIT License (<http://opensource.org/licenses/MIT>).mozilla β The distribution is licensed under the Mozilla Public License.
(<http://opensource.org/licenses/MPL-1.0> or <http://opensource.org/licenses/MPL-1.1>)open_source β The distribution is licensed under some other Open Source Initiativeβapproved license listed
at <http://www.opensource.org/licenses/>.perl β The distribution may be copied and redistributed under the same terms as perl itself (this
is by far the most common licensing option for modules on CPAN). This is a dual license, in
which the user may choose between either the GPL or the Artistic license.restrictive β The distribution may not be redistributed without special permission from the author and/or
copyright holder.unrestricted β The distribution is licensed under a license that is not approved by www.opensource.org
<http://www.opensource.org/> but that allows distribution without restrictions.Example:
distribution_type: module
(Spec 1.0) [optional] {string} What kind of stuff is contained in this distribution. Most things
on CPAN are "module"s (which can also mean a collection of modules), but some things are
"script"s.
Unfortunately this field is basically meaningless, since many distributions are hybrids of several kinds of things, or some new thing, or subjectively different in focus depending on who's using them. Tools like Module::Build and MakeMaker will likely stop generating this field.
Example:
requires:
Data::Dumper: 0
File::Find: 1.03
(Spec 1.0) [optional] {map} A YAML mapping indicating the Perl prerequisites this distribution
requires for proper operation. The keys are the names of the prerequisites (module names or
'perl'), and the values are version specifications as described in VERSION SPECIFICATIONS.
Example:
recommends:
Data::Dumper: 0
File::Find: 1.03
(Spec 1.0) [optional] {map} A YAML mapping indicating the Perl prerequisites this distribution
recommends for enhanced operation. The keys are the names of the prerequisites (module names or
'perl'), and the values are version specifications as described in VERSION SPECIFICATIONS.
*ALTERNATIVE: It may be desirable to present to the user which features depend on which modules so they can make an informed decision about which recommended modules to install.*
Example:
optional_features:
foo:
description: Provides the ability to blah.
requires:
Data::Dumper: 0
File::Find: 1.03
(Spec 1.1) [optional] {map} A YAML mapping of names for optional features which are made
available when its requirements are met. For each feature a description is provided along with
any of requires, build_requires, and conflicts, which have the same meaning in this
subcontext as described elsewhere in this document.
Example:
build_requires:
Data::Dumper: 0
File::Find: 1.03
(Spec 1.0) [optional] {map} A YAML mapping indicating the Perl prerequisites required for
building and/or testing of this distribution. The keys are the names of the prerequisites
(module names or 'perl'), and the values are version specifications as described in "VERSION
SPECIFICATIONS". These dependencies are not required after the distribution is installed.
Example:
configure_requires:
Module::Build: 0.2809
Data::Dumper: 0
File::Find: 1.03
(Spec 1.4) [optional] {map} A YAML mapping indicating the Perl prerequisites required before
configuring this distribution. The keys are the names of the prerequisites (module names or
'perl'), and the values are version specifications as described in "VERSION SPECIFICATIONS".
These dependencies are not required after the distribution is installed.
Example:
conflicts:
Data::Dumper: 0
File::Find: 1.03
(Spec 1.0) [optional] {map} A YAML mapping indicating any items that cannot be installed while
this distribution is installed. This is a pretty uncommon situation. The keys for conflicts
are the item names (module names or 'perl'), and the values are version specifications as
described in "VERSION SPECIFICATIONS".
Example:
dynamic_config: 0
(Spec 1.0) [optional] {boolean} A boolean flag indicating whether a Build.PL or Makefile.PL (or similar) must be executed when building this distribution, or whether it can be built, tested and installed solely from consulting its metadata file. The main reason to set this to a true value is that your module performs some dynamic configuration (asking questions, sensing the environment, etc.) as part of its build/install process.
Currently Module::Build doesn't actually do anything with this flag β it's probably going to be up to higher-level tools like CPAN to do something useful with it. It can potentially bring lots of security, packaging, and convenience improvements.
If this field is omitted, it defaults to 1 (true).
(Deprecated) (Spec 1.0) [optional] {map} This field has been renamed to no_index. See below.
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.1) [optional] {map} A YAML mapping that describes all packages provided by this distribution. This information can be (and, in some cases, 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.
When using tools like Module::Build that can generate the provides mapping for your
distribution automatically, make sure you examine what it generates to make sure it makes sense
β indexers will usually trust the provides field if it's present, rather than scanning through
the distribution files themselves to figure out packages and versions. This is a good thing,
because it means you can use the provides field to tell the indexers precisely what you want
indexed about your distribution, rather than relying on them to essentially guess what you want
indexed.
Example:
no_index:
file:
- My/Module.pm
directory:
- My/Private
package:
- My::Module::Stuff
namespace:
- My::Module::Stuff
(Spec 1.1) [optional] {map} A YAML mapping that describes any files, directories, packages, and
namespaces that are private (i.e. implementation artifacts) that are not of interest to
searching and indexing tools. This is useful when no provides field is present.
For example, <http://search.cpan.org/> excludes items listed in no_index when searching for
POD, meaning files in these directories will not converted to HTML and made public β which is
useful if you have example or test PODs that you don't want the search engine to go through.
"dir" instead of "directory", but I think MakeMaker and
various users started using "directory", so in deference we switched to that.]Example:
keywords:
- make
- build
- install
(Spec 1.1) [optional] {list} A sequence of keywords/phrases that describe this distribution.
Example:
resources:
license: http://dev.perl.org/licenses/
homepage: http://sourceforge.net/projects/module-build
bugtracker: http://rt.cpan.org/NoAuth/Bugs.html?Dist=Module-Build
repository: http://sourceforge.net/cvs/?group_id=45731
MailingList: http://lists.sourceforge.net/lists/listinfo/module-build-general
(Spec 1.1) [optional] {map} A mapping of any URL resources related to this distribution.
Allβlowerβcase keys, such as homepage, license, and bugtracker, are reserved by this
specification, as they have "official" meanings defined here in this specification. If you'd
like to add your own "special" entries (like the MailingList entry above), use at least one
upperβcase letter.
The current set of official keys is:
Example:
generated_by: Module::Build version 0.20
(Spec 1.0) [required] {string} Indicates the tool that was used to create this META.yml file. It's good form to include both the name of the tool and its version, but this field is essentially opaque, at least for the moment. If META.yml was generated by hand, it is suggested that the author be specified here.
[Note: My meta_stats.pl script which I use to gather statistics regarding META.yml usage prefers the form listed above, i.e. it splits on /\s+version\s+/ taking the first field as the name of the tool that generated the file and the second field as version of that tool. RWS]
requires, recommends, build_requires,
etc.) to indicate the particular version(s) of some other module that may be required as a
prerequisite. This section details the version specification formats that are currently
supported.
The simplest format for a version specification 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.
You may also 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.
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.
dynamic_config field, which was missing from the initial version.private field.abstract, configure, requires_packages, requires_os, excludes_os, and
no_index fields.generation, authored_by fields.recommends field.requires_build_tools field.auto_regenerate field.index field as a complement to no_index.keywords field as a means to aid searching distributions.generation, requires_build_tools, requires_packages, configure,
requires_os, excludes_os, auto_regenerate) that have never actually been supported, but
were more like records of brainstorming.authored_by to author, since that's always been what it's actually called in
actual META.yml files.== operator to the list of supported versionβchecking operators.distribution_type field is basically meaningless, and shouldn't really be
used.dynamic_config a bit.CPAN::META::Specification, since that implies a module that doesn't
actually exist.configure_requires.Generated by phpman v4.9.26-5-g7740029 · Markdown · JSON · MCP Author: Che Dong Under GNU General Public License
2026-08-24 08:32 @216.73.216.102
CrawledBy Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)