view release on metacpan or  search on metacpan

lib/CPAN/Meta/History/Meta_1_4.pod  view on Meta::CPAN

cannot be installed while this distribution is installed.  This is a
pretty uncommon situation.  The keys for C<conflicts> are the item
names (module names or 'perl'), and the values are version
specifications as described in L</"VERSION SPECIFICATIONS">.


=head2 dynamic_config

Example:

  dynamic_config: 0

(Spec 1.0) [optional] {boolean} A boolean flag indicating whether a F<Build.PL>
or F<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).

=head2 private

I<(Deprecated)> (Spec 1.0) [optional] {map} This field has been renamed to
L</no_index>.  See below.

=head2 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.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 L<Module::Build> that can generate the
C<provides> mapping for your distribution automatically, make sure you
examine what it generates to make sure it makes sense - indexers will
usually trust the C<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 C<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.

=head2 no_index

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 C<provides> field is
present.

For example, L<http://search.cpan.org/> excludes items listed in C<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.

=head3 file

(Spec 1.1) [optional] Exclude any listed file(s).

=head3 directory

(Spec 1.1) [optional] Exclude anything below the listed
directory(ies).

[Note: previous editions of the spec had C<dir> instead of
C<directory>, but I think MakeMaker and various users started using
C<directory>, so in deference we switched to that.]

=head3 package

(Spec 1.1) [optional] Exclude the listed package(s).

=head3 namespace

(Spec 1.1) [optional] Excludes anything below the listed namespace(s),
but I<not> the listed namespace(s) its self.

=head2 keywords

Example:

  keywords:
    - make
    - build
    - install

(Spec 1.1) [optional] {list} A sequence of keywords/phrases that describe
this distribution.