=head1 NAME

​

cpanfile-faq - cpanfile FAQ

​

=head1 QUESTIONS

​

=head2 Does cpanfile replace Makefile.PL/Build.PL or META.yml/json?

​

No, it doesn't. C<cpanfile> is a simpler way to declare CPAN

dependencies, mainly for I<your application> rather than CPAN

distributions.

​

However, while CPAN distributions do not need to B<switch> to

C<cpanfile>, you can certainly I<manage> the dependencies in

C<cpanfile>, then export them into C<META.json> files when shipping to

CPAN, using tools such as L<Dist::Milla> or L<Module::Install::CPANfile>

​

=head2 Why do we need yet another format?

​

Here are some of the reasons that motivates the new L<cpanfile>

format.

​

=over 4

​

=item Not everything is a CPAN distribution

​

First of all, it is annoying to write (a dummy) C<Makefile.PL> when

what you develop is not a CPAN distribution, just so that installation

like C<cpanm --installdeps .> would work.

​

It gets more painful when you develop a web application that you want

to deploy on a different environment using version control system

(such as PaaS/cloud infrastructure), because it requires you to often

commit the META file or C<inc/> directory (or even worse, both) to a

repository.

​

Many web application frameworks generate a boiler-plate C<Makefile.PL>

for dependency declaration and to let you install dependencies with

C<< cpanm --installdeps . >>, but that doesn't always mean they are

meant to be installed. Things can be often much simpler if you run the

application from the checkout directory.

​

With L<cpanfile>, dependencies can be installed either globally or