Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Contact Us
Online Help
Domain Status
Man Pages

Virtual Servers

Topology Map

Server Agreement
Year 2038

USA Flag



Man Pages

Manual Reference Pages  -  MODULE::INSTALL::API (3)

.ds Aq ’


Module::Install::API - Command Reference for Module::Install



Module::Install has lots of commands scattered in the extensions. Several common commands are described in the main Module::Install’s pod, but you usually need to know more to do what you want.

This API document lists and describes all the public supported commands, grouped by the nature or importance of them.

If you are a module author and want to use Module::Install in your distributions, this is the document you should consult.

If you are a user (or a contributor) of distributions that use Module::Install, you may also want to check Module::Install::FAQ where you’ll find some common glitches you may encounter.

Note that commands not listed here should be deemed private utility commands for the Module::Install developers, or unsupported 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.


Most of these are also described in the main Module::Install’s pod. Basically, (almost) all you have to know is the <B>all_fromB> 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 all_from() not to be warned by the lack of information).

    all_from (Module::Install::Metadata)

  all_from lib/Foo/;

<B>all_fromB> 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.

    name, name_from, module_name (Module::Install::Metadata)

  name Foo-Bar;
  name_from lib/Foo/;

<B>nameB> commmand 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>name_fromB> takes a module file path, and looks for the topmost package declaration to extract a module name, and then converts it to a distribution name.

You may optionally set <B>module_nameB> to specify a main module name (if you choose other naming scheme for your distribution). This value is directly passed to ExtUtils::MakeMaker in the backend as a NAME attribute (Module::Install usually creates this from the distribution name set by <B>nameB> or <B>name_fromB>).

    abstract, abstract_from (Module::Install::Metadata)

  abstract a short description of the distribution;
  abstract_from lib/Foo/;

<B>abstractB> command takes a string to describe what that module/distribution is for. <B>abstract_fromB> takes a module file path and looks for a string that follows the module’s name and a hyphen to separate in the NAME section of the pod.

The value set by <B>abstractB> or <B>abstract_fromB> is passed to ExtUtils::MakeMaker as an ABSTRACT attribute.

    version, version_from (Module::Install::Metadata)

  version 0.01;
  version_from lib/Foo/;

<B>versionB> command takes a version string for the distribution. <B>version_fromB> takes a module file path, and looks for the $VERSION of the module.

The value set by <B>versionB> or <B>version_fromB> is passed to ExtUtils::MakeMaker as a VERSION attribute. <B>version_fromB> (and <B>all_fromB>) also sets a VERSION_FROM attribute to check version integrity of the distribution.

    perl_version, perl_version_from (Module::Install::Metadata)

  perl_version 5.008;
  perl_version_from lib/Foo/;

<B>perl_versionB> command takes a minimum required perl version for the distribution. <B>perl_version_fromB> takes a module file path, and looks for a use <perl_version> (or require <perl_version>) statement (note that now Module::Install only supports perl 5.005 and newer).

The value set by <B>perl_versionB> or <B>perl_version_fromB> is passed to ExtUtils::MakeMaker as a MIN_PERL_VERSION attribute (if applicable).

    author, author_from (Module::Install::Metadata)

  author John Doe <john.doe at>;
  author_from lib/Foo/;

<B>authorB> command takes a string to describe author(s). You can set multiple authors with one <B>authorB> command, or with multiple <B>authorB>s (you can also use <B>authorsB> alias if you prefer).

<B>author_fromB> takes a module file path, and looks for an AUTHOR (or AUTHORS) 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>authorB> or <B>author_fromB> is concatenated and passed to ExtUtils::MakeMaker as an AUTHOR attribute.

    license, license_from (Module::Install::Metadata)

  license perl;
  license_from lib/Foo/;

<B>licenseB> command takes an abbreviated license name including perl, artistic, apache, (l)gpl, bsd, mit, mozilla, open_source, and so on. If you don’t (want to) specify a particular license, it will be unknown.

<B>license_fromB> takes a module file path, and looks for a LICENSE (or LICENCE) section in the pod (and also COPYRIGHT section if it can’t find any) to extract a license.

The value set by <B>licenseB> or <B>license_fromB> is passed to ExtUtils::MakeMaker as an LICENSE attribute (if applicable).

You are also reminded that if the distribution is intended to be uploaded to the CPAN, it <B>mustB> be an OSI-approved open source license. Commercial software is not permitted on the CPAN.


Most of these are described in the main pod, too.

    requires (Module::Install::Metadata)

  requires Foo::Bar;
  requires Foo::Baz => 1.00;

<B>requiresB> command takes a module name on which your distribution depends, and its minimum required version if any. You may add arbitrary numbers of requires. 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>requiresB> are passed to ExtUtils::MakeMaker as a PREREQ_PM attribute.

    build_requires, test_requires (Module::Install::Metadata)

  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>build_requiresB> command also takes a module name and a minimum required version if any. The difference from the requires command is that <B>build_requiresB> 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, test_requires is just an alias for build_requires, but this may change in the future.

The values set by <B>build_requiresB> and <B>test_requiresB> are passed to ExtUtils::MakeMaker as a BUILD_REQUIRES attribute, which may fall back to PREREQ_PM if your ExtUtils::MakeMaker is not new enough.

    configure_requires (Module::Install::Metadata)

  configure_requires ExtUtils::Foo::Bar;
  configure_requires ExtUtils::Foo::Baz => 1.00;

<B>configure_requiresB> command also takes a module name and a minimum required version if any. The difference from the requires command is that <B>configure_requiresB> is to call for modules you’ll require to run perl Makefile.PL. This attribute only makes sense for the latest CPAN toolchains that parse META.yml before running perl Makefile.PL.

The values set by <B>configure_requiresB> are passed to ExtUtils::MakeMaker as a CONFIGURE_REQUIRES attribute, which may fall back to PREREQ_PM if your ExtUtils::MakeMaker is not new enough.

    recommends (Module::Install::Metadata)

  recommends ExtUtils::Foo::Bar;
  recommends ExtUtils::Foo::Baz => 1.00;

<B>recommendsB> command also takes a module name and a minimum required version if any. As of this writing, recommends is purely advisory, only written in the META.yml. Recommended modules will <B>notB> usually be installed by the current CPAN toolchains (other system package managers may possibly prompt you to install them).

    features, feature (Module::Install::Metadata)

  feature( share directory support,
    -default => 1,
    File::ShareDir => 1.00,

    JSON support, [
      -default => 0,
      JSON => 2.00,
      JSON::XS => 2.00,
    YAML support, [
      YAML => 0,

<B>featureB> command takes a string to describe what the feature is for, and an array of (optional) modules and their recommended versions if any. <B>featuresB> command takes an array of a description and an array of modules.

As of this writing, both feature and features work only when <B>auto_installB> (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 featured modules are optional and can be chosen during the installation, the chosen modules are treated the same as the ones set by requires command. (They are not listed in the recommends section in the META.yml). This may change in the future.

You can add -default => [01] in an array of required modules in the feature(s), to set a default value for the prompt.


These are the commands to write actual meta files.

    WriteAll (Module::Install::WriteAll)

  use inc::Module::Install;
  all_from lib/Foo/;

<B>WriteAllB> command is usually the last command in the Makefile.PL. It can take several attributes, but you usually don’t need to care unless you want to write a Makefile for an Inline-based module. This writes Makefile, META.yml, and MYMETA.yml (or MYMETA.json) if you set an experimental environmental variable X_MYMETA.

    WriteMakefile (Module::Install::MakeMaker)

  use inc::Module::Install;
  requires Foo::Baz;  # a la Module::Install
  WriteMakefile(        # a la ExtUtils::MakeMaker
    NAME => Foo::Bar,
    VERSION_FROM => lib/Foo/,

If you’re familiar with ExtUtils::MakeMaker and generally want to stick to its way, you can. Use as much Module::Install’s magic as you want, and then fall back to the good and old way. It just works.

    write_mymeta_yaml, write_mymeta_json (Module::Install::Metadata)


<B>write_mymeta_yamlB> command and <B>write_mymeta_jsonB> command are to write MYMETA.yml and MYMETA.json 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 WriteAll command) but you can explicitly write these commands in your Makefile.PL.


    makemaker_args (Module::Install::Makefile)

    PREREQ_FATAL => 1,
    dist => { PREOP => pod2text lib/Foo/ > README },

<B>makemaker_argsB> command is used in WriteMakefile command, and takes any attributes ExtUtils::MakeMaker understands. See ExtUtils::MakeMaker for the available attributes.

    preamble, postamble (Module::Install::Makefile)

  preamble "# my preamble\n";
  postamble qq{my_done ::\n\t\$(PERL) -e "print qq/done\\n/"\n};

<B>preambleB> and <B>postambleB> commands take a string to be embedded in the Makefile. You can add custom targets with this. See appropriate manuals to learn how to write Makefile.


These are to set test files.

    tests (Module::Install::Metadata)

  tests t/*.t t/*/*.t;

<B>testsB> 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 tests by any means (with explicit tests command, or extensions like Module::Install::AuthorTests or Module::Install::ExtraTests), and if you have an xt directory, Module::Install silently adds those tests under the xt directory when you are in the author mode, or you are doing release testing (with RELEASE_TESTING environmental variable).

The value set by <B>testsB> is passed to ExtUtils::MakeMaker as a test attribute.

    tests_recurisve (Module::Install::Makefile)


<B>tests_recursiveB> 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.


    installdirs (Module::Install::Metadata)

  installdirs site;

<B>installdirsB> 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>installdirsB> is passed to ExtUtils::MakeMaker as an INSTALLDIRS attribute.

    install_as_core, install_as_cpan, install_as_site, install_as_vendor (Module::Install::Metadata)

  install_as_core;   # = installdirs perl;
  install_as_cpan;   # = installdirs site;
  install_as_site;   # = installdirs site;
  install_as_vendor; # = installdirs vendor;

<B>install_as_*B> commands are aliases of the corresponding commands shown in the comments above.


These are to install files other than the ones under the lib directory.

    install_script (Module::Install::Scripts)


<B>install_scriptB> command takes a script file name, and installs it into a script directory for your Perl installation. If your script is in a script directory, you can omit the script/ part.

The value set by <B>install_scriptB> is passed to ExtUtils::MakeMaker as an EXE_FILES attribute.

    install_share (Module::Install::Share)

  install_share(dist, templates);
  install_share(module, My::WebApp, share);

<B>install_shareB> command may take a directory type (either dist or module), a module name if necessary, and a directory (share by default), and installs files under the directory into a share directory for the type, which is usually in a directory your perl is installed in (but this may not be true if you’re using local::lib and the likes).

You can access these shared files via File::ShareDir’s dist_file or module_file according to the type. Note also that a shared directory is usually read-only. You can’t use this as a private temporary directory.


    auto_install (Module::Install::AutoInstall)


The <B>auto_installB> command is used to allow users to install dependencies of a local project when you run make after <perl Makefile.PL>. In the past this was the only sane way to pull extra dependencies without installing the actual module, although now there are some alternatives (which however do <B>notB> completely replace auto_install). For example you can use cpan . (with newer CPAN) or cpanm --installdeps . (with App::cpanminus).

auto_install also enables feature(s) commands to choose what you install (keep in mind that using feature() in CPAN distributions is generally considered a bad practice).


Module::Install 0.96 and above installs distributions in the subdirectories by default as ExtUtils::MakeMaker does. You also can specify what to install one by one.

    build_subdirs (Module::Install::Makefile)

  build_subdirs win32 if $^O eq MSWin32;

<B>build_subdirsB> command takes subdirectories where projects you want to install are in. The values set by <B>build_subdirsB> are passed to ExtUtils::MakeMaker as a DIR attribute.


These are to provide optional meta data mainly used by the PAUSE indexer and the CPAN search site. See also the META-spec page (<>) for details.

    no_index (Module::Install::Metadata)

  no_index file      => lib/My/Test/;
  no_index directory => templates;
  no_index package   => Test::Foo::Bar;
  no_index namespace => Test::Foo::Bar;

<B>no_indexB> command takes a hash to describe what should be excluded from the PAUSE index etc. Module::Install provides several no_index directories by default, including inc, share, (x)t, test, example(s), demo.

    resources (Module::Install::Metadata)

    license     => "",
    homepage    => "",
    bugtracker  => "",
    repository  => "",
    MailingList => "";

<B>resourcesB> command takes a hash that contains various URLs for the related resources. Keys in lower-case are reserved. These resources are written in the META.yml.

    homepage, bugtracker, repository (Module::Install::Metadata)


<B>homepageB>, <B>bugtrackerB>, and repository commands take a URL for the corresponding resource.


There are several commands to bundle modules/distributions in your distribution, but they are still broken in general. Don’t use them for now.


    libs (Module::Install::Makefile), cc_lib_paths, cc_lib_links (Module::Install::Compiler)

  libs -lz;
  libs [qw/-lz -Llibs/];
  cc_lib_paths libs;
  cc_lib_links qw/z iconv/;

<B>libsB> command takes a string, or an array reference of strings to be passed to ExtUtils::MakeMaker as a LIBS attribute. <B>cc_lib_pathsB> and <B>cc_lib_linksB> are its alternatives, both of which take an array of strings. cc_lib_paths is for upper-cased -L (directories), and cc_lib_links is for lower-cased -l (libraries).

    inc (Module::Install::Makefile), cc_inc_paths (Module::Install::Compiler)

  inc -I. -Iinclude;
  cc_inc_paths qw/. include/;

<B>incB> command takes a string to be passed to ExtUtils::MakeMaker as an INC attribute. <B>cc_inc_pathsB> is its alternative, and takes an array of directories.

    cc_optimize_flags (Module::Install::Compiler)

  cc_optimize_flags -O2;

<B>cc_optimize_flagsB> takes a string to be passed to ExtUtils::MakeMaker as an OPTIMIZE attribute.

    ppport (Module::Install::Compiler)


<B>ppportB> command is used to bundle ppport.h to a distribution.

    requires_external_cc (Module::Install::External)


<B>requires_external_ccB> command checks if the user has a working compiler listed in the Config, and exits the Makefile.PL if none is found.

    can_cc (Module::Install::Can)

  exit 0 unless can_cc;

<B>can_ccB> command tells if the use has a working compiler or not.


    clean_files, realclean_files (Module::Install::Makefile)

  clean_files *.o Foo-*;
  realclean_files *.o Foo-*;

<B>clean_filesB> command takes a string or an array of strings, concatenates them with spaces, and passes the result to ExtUtils::MakeMaker as a clean attribute. <B>realclean_filesB> does the same for a realclean attribute.


    can_use (Module::Install::Can)

  if (can_use(Some::Module, 0.05)) {

<B>can_useB> command takes a module name, and optionally a version, and checks if the module (with the version if appropriate) is installed or not.

    can_run (Module::Install::Can)

  if (can_run(svn)) {
    # do something with the C<svn> binary

<B>can_runB> command takes a executable path, and checks if the executable is available or not.

    requires_external_bin (Module::Install::External)

  requires_external_bin svn;

<B>requires_external_binB> command takes a executable path, and exits the Makefile.PL if none is available.


Kenichi Ishigaki <>


Copyright 2010 Kenichi Ishigaki.

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

Search for    or go to Top of page |  Section 3 |  Main Index

perl v5.20.3 MODULE::INSTALL::API (3) 2015-05-02

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.