=pod =head1 NAME Module::Install::API - Command Reference for Module::Install =head1 DESCRIPTION L has lots of commands scattered in the extensions. Several common commands are described in the main L's pod, but you usually need to know more to do what you want. This API document lists and describes all the public I commands, grouped by the nature or importance of them. If you are a module author and want to use L in your distributions, this is the document you should consult. If you are a user (or a contributor) of distributions that use L, you may also want to check L where you'll find some common glitches you may encounter. Note that commands not listed here should be deemed private utility commands for the L developers, or I commands with various reasons (some are experimental and half-baked, some are broken (by design or by implementation), some are simply deprecated, and so on). You may find some of them are used rather widely, but their use is discouraged. You have been warned. =head1 COMMANDS TO PROVIDE BASIC META DATA Most of these are also described in the main L's pod. Basically, (almost) all you have to know is the B command that tries to extract all the necessary basic meta data from a module file, but you can also specify one by one what is not written in the module and can't be extracted (you usually want to write these specific commands before C not to be warned by the lack of information). =head2 all_from (L) all_from 'lib/Foo/Bar.pm'; B command takes a module file path, and will try to extract meta data from the module including a distribution name, a module version, the minimum required perl version for the module, authors information, a license, a short description of the module. See the following commands for the extraction detail. =head2 name, name_from, module_name (L) name 'Foo-Bar'; name_from 'lib/Foo/Bar.pm'; B command takes a distribution name. It usually differs slightly from a module name (a module name is separated by double colons; a distribution name is separated by hyphens). Just replacing all the double colons of your main module with hyphens would be enough for you. B takes a module file path, and looks for the topmost C declaration to extract a module name, and then converts it to a distribution name. You may optionally set B to specify a main module name (if you choose other naming scheme for your distribution). This value is directly passed to L in the backend as a C attribute (Module::Install usually creates this from the distribution name set by B or B). =head2 abstract, abstract_from (L) abstract 'a short description of the distribution'; abstract_from 'lib/Foo/Bar.pm'; B command takes a string to describe what that module/distribution is for. B takes a module file path and looks for a string that follows the module's name and a hyphen to separate in the C section of the pod. The value set by B or B is passed to L as an C attribute. =head2 version, version_from (L) version '0.01'; version_from 'lib/Foo/Bar.pm'; B command takes a version string for the distribution. B takes a module file path, and looks for the C<$VERSION> of the module. The value set by B or B is passed to L as a C attribute. B (and B) also sets a C attribute to check version integrity of the distribution. =head2 perl_version, perl_version_from (L) perl_version '5.008'; perl_version_from 'lib/Foo/Bar.pm'; B command takes a minimum required perl version for the distribution. B takes a module file path, and looks for a C<< use >> (or C<< require >>) statement (note that now L only supports perl 5.005 and newer). The value set by B or B is passed to L as a C attribute (if applicable). =head2 author, author_from (L) author 'John Doe '; author_from 'lib/Foo/Bar.pm'; B command takes a string to describe author(s). You can set multiple authors with one B command, or with multiple Bs (you can also use B alias if you prefer). B takes a module file path, and looks for an C (or C) section in the pod (and also license/copyright sections if it can't find any author(s) section) to extract an author. The value set by B or B is concatenated and passed to L as an C attribute. =head2 license, license_from (L) license 'perl'; license_from 'lib/Foo/Bar.pm'; B command takes an abbreviated license name including C, C, C, C<(l)gpl>, C, C, C, C, and so on. If you don't (want to) specify a particular license, it will be C. B takes a module file path, and looks for a C (or C) section in the pod (and also C section if it can't find any) to extract a license. The value set by B or B is passed to L as an C attribute (if applicable). You are also reminded that if the distribution is intended to be uploaded to the CPAN, it B be an OSI-approved open source license. Commercial software is not permitted on the CPAN. =head1 COMMANDS TO PROVIDE DEPENDENCIES Most of these are described in the main pod, too. =head2 requires (L) requires 'Foo::Bar'; requires 'Foo::Baz' => '1.00'; B command takes a module name on which your distribution depends, and its minimum required version if any. You may add arbitrary numbers of C. You even can add multiple numbers of dependencies on the same module with different required versions (which will be sorted out later, though). Note that this dependency is on the basis of a module, not of a distribution. This usually doesn't matter, and you just need to call for a module you really need (then you'll get the whole distribution it belongs to), but sometimes you may need to call for all the modules that the required module implicitly requires. The values set by B are passed to L as a C attribute. =head2 build_requires, test_requires (L) build_requires 'ExtUtils::Foo::Bar'; build_requires 'ExtUtils::Foo::Baz' => '1.00'; test_requires 'Test::Foo::Bar'; test_requires 'Test::Foo::Baz' => '1.00'; B command also takes a module name and a minimum required version if any. The difference from the C command is that B is to call for modules you'll require while building the distribution, or in the tests, and that in theory are not required at run-time. This distinction is more for other system package managers than for the CPAN, from where you usually want to install everything for future reuse (unless you are too lazy to test distributions). As of this writing, C is just an alias for C, but this may change in the future. The values set by B and B are passed to L as a C attribute, which may fall back to C if your L is not new enough. =begin experimental =head2 install_requires (L) install_requires 'Test::Foo::Bar'; install_requires 'Test::Foo::Baz' => '1.00'; B is yet another alias for C. This is not used yet. =end experimental =head2 configure_requires (L) configure_requires 'ExtUtils::Foo::Bar'; configure_requires 'ExtUtils::Foo::Baz' => '1.00'; B command also takes a module name and a minimum required version if any. The difference from the C command is that B is to call for modules you'll require to run C<< perl Makefile.PL >>. This attribute only makes sense for the latest CPAN toolchains that parse C before running C<< perl Makefile.PL >>. The values set by B are passed to L as a C attribute, which may fall back to C if your L is not new enough. =begin experimental =head2 requires_from, test_requires_from (L) requires_from 'lib/Foo/Bar.pm'; test_requires_from 't/00-compile.t'; B command takes a module file path, and looks for C statements with explicit module version (like C<< use Foo::Bar 0.01 >>), and from which it sets C attributes. B commands also takes a file path but of a test file, and looks for the same C statements to set B attributes. Both are experimental and only work if the statements have an explicit version number (which you rarely append...). This behavior may change in the future. =end experimental =head2 recommends (L) recommends 'ExtUtils::Foo::Bar'; recommends 'ExtUtils::Foo::Baz' => '1.00'; B command also takes a module name and a minimum required version if any. As of this writing, C is purely advisory, only written in the C. Recommended modules will B usually be installed by the current CPAN toolchains (other system package managers may possibly prompt you to install them). =head2 features, feature (L) feature( 'share directory support', -default => 1, 'File::ShareDir' => '1.00', ); features( 'JSON support', [ -default => 0, 'JSON::MaybeXS' => '1.003003', ], 'YAML support', [ 'YAML' => '0', ], ); B command takes a string to describe what the feature is for, and an array of (optional) modules and their recommended versions if any. B command takes an array of a description and an array of modules. As of this writing, both C and C work only when B (see below) is set. These are used to allow distribution users to choose what they install along with the distribution. This may be useful if the distribution has lots of optional features that may not work on all the platforms, or that require too many modules for average users. However, prompting users also hinders automated installation or smoke testing, and is considered a bad practice (giving sane default values is much preferred). Though Cd modules are optional and can be chosen during the installation, the chosen modules are treated the same as the ones set by C command. (They are not listed in the C section in the C). This may change in the future. You can add C<< -default => [01] >> in an array of required modules in the C, to set a default value for the prompt. =head1 COMMANDS TO WRITE METADATA These are the commands to write actual meta files. =head2 WriteAll (L) use inc::Module::Install; all_from 'lib/Foo/Bar.pm'; WriteAll; B command is usually the last command in the C. It can take several attributes, but you usually don't need to care unless you want to write a Makefile for an L-based module. This writes C, C, and C (or C) if you set an experimental environmental variable C. =head2 WriteMakefile (L) use inc::Module::Install; requires 'Foo::Baz'; # a la Module::Install WriteMakefile( # a la ExtUtils::MakeMaker NAME => 'Foo::Bar', VERSION_FROM => 'lib/Foo/Bar.pm', ); If you're familiar with L and generally want to stick to its way, you can. Use as much L's magic as you want, and then fall back to the good and old way. It just works. =head2 write_mymeta_yaml, write_mymeta_json (L) write_mymeta_yaml; write_mymeta_json; B command and B command are to write C and C respectively, which are new enhancement for the CPAN toolchains that eventually will allow toolchain modules to know what modules are required without parsing Makefile etc. These are mainly for internal use (in the C command) but you can explicitly write these commands in your Makefile.PL. =begin internal =head2 Meta (L) Meta->write; B represents a L object. You can use it to do some OO-ish things but you usually have other ways to do the same thing. =head2 Makefile (L) Makefile->write; B represents a L object. You can use it to do some OO-ish things but you usually have other ways to do the same thing. =head2 Inline (L) Inline->write; B represents a L object. You can use it to do some OO-ish things but you usually have other ways to do the same thing. =end internal =head1 COMMANDS TO TWEAK MAKEFILE =head2 makemaker_args (L) makemaker_args( PREREQ_FATAL => 1, dist => { PREOP => 'pod2text lib/Foo/Bar.pm > README' }, ); B command is used in C command, and takes any attributes L understands. See L for the available attributes. =head2 preamble, postamble (L) preamble "# my preamble\n"; postamble qq{my_done ::\n\t\$(PERL) -e "print qq/done\\n/"\n}; B and B commands take a string to be embedded in the C. You can add custom targets with this. See appropriate manuals to learn how to write Makefile. =head1 COMMANDS FOR TESTS These are to set test files. =head2 tests (L) tests 't/*.t t/*/*.t'; B command takes a string to specify test files. You can use wildcard characters, and if you want to run tests under several directories, concatenates the specs with white spaces. If you haven't set C by any means (with explicit C command, or extensions like L or L), and if you have an C directory, L silently adds those tests under the C directory when you are in the author mode, or you are doing release testing (with C environmental variable). The value set by B is passed to L as a C attribute. =head2 tests_recurisve (L) tests_recursive; tests_recursive('t'); B command may take a directory, and looks for test files under it recursively. As of this writing, you can't use this command with other test related commands. =head1 COMMANDS TO TWEAK DIRECTORIES TO INSTALL =head2 installdirs (L) installdirs 'site'; B command takes a directory type, and changes a directory to install modules and so on, though you usually don't need to use this. The value set by B is passed to L as an C attribute. =head2 install_as_core, install_as_cpan, install_as_site, install_as_vendor (L) install_as_core; # = installdirs 'perl'; install_as_cpan; # = installdirs 'site'; install_as_site; # = installdirs 'site'; install_as_vendor; # = installdirs 'vendor'; B commands are aliases of the corresponding commands shown in the comments above. =head1 COMMANDS TO INSTALL SUBORDINATE FILES These are to install files other than the ones under the C directory. =head2 install_script (L) install_script('foo'); install_script('script/foo'); B command takes a script file name, and installs it into a C