view release on metacpan or  search on metacpan

local/lib/perl5/Module/Install/FAQ.pod  view on Meta::CPAN

=pod

=head1 NAME

Module::Install::FAQ - Frequently Asked Questions for Module::Install

=head1 DESCRIPTION

Though L<Module::Install> itself has a general FAQ section in the
pod, it's more for advocacy. Here's an incomplete and growing list of
the actual questions I have been frequently asked (or found on the
net) about L<Module::Install>.

=head2 Do I also have to update my CPAN modules every time Module::Install is updated?

The point of L<Module::Install> is let module authors take care of
everything related to updating toolchains for the sake of module
users. So, if you choose to use L<Module::Install>, it's you who
should update toolchains, i.e. L<Module::Install> and other bundled
modules. You should check if there's any significant change/fix in
your toolchains. You should check if your toolchains go along with
other tools users use to install your distributions, or with
the systems users are in, or whatever that matters. In the end,
you are expected to have much more knowledge and willingness than
average users.

That being said, practically, you don't have to update your
distributions if they are working well. But if you do find issues,
please update your distributions, even when you have nothing to
change in your own modules. L<Module::Install> is not only a tool to
write better, but also a tool to encourage you to help others.

=head2 Do I really have to avoid auto_install()?

Not at all, B<using C<auto_install()> is just fine>. While it indeed
behaved erratically in older L<Module::Install> versions, there have
been no reported issues since mid-2009. As far as compatibility with
various CPAN clients: several rather large projects on CPAN (including
L<Catalyst> and L<DBIx::Class>), are using C<auto_install> without any
issues reported by their substantial userbases.

That said, if all you want to do is make it easy for a contributor to
checkout your code and quickly install necessary dependencies, there
are alternatives to C<auto_install>.

If your L<CPAN> module is new enough, you can pass a dot to the
B<cpan> command it provides, and it will install all the required
distributions from the CPAN:

  $ cpan .

The same is true for the B<cpanm> command from L<App::cpanminus>,
with which you even can write like C<< cpanm --installdeps . >>

=head2 Should I put an "inc" directory Module::Install automatically creates into a repository for my projects?

Depends. If the repository is private and only for you, you usually
don't want to put it in your repository to let you always use the
latest L<Module::Install> you have (the C<inc> directory is recreated
each time you run C<perl Makefile.PL>).

If not, but you alone are the release manager and know what you have
to do when you release, putting the C<inc> directory into your
repository may help other casual contributors, especially if you use
minor (or private) non-core extensions in your Makefile.PL.

However, if you generously allow other people to release, or you're
not so familiar with how L<Module::Install> works and don't know what
you have to do in the above situation, B<don't> put it in the
repository. It may be the cause of troubles including a wrong version
in the C<META.yml>.

If you feel sorry about the inconvenience for your fellow
contributors, you may want to add explicitly C<< use