cpanfile-faq - cpanfile FAQ
No, it doesn't.
cpanfile is a simpler way to declare CPAN dependencies, mainly to your application rather than CPAN distributions. It can also be used as a format to manage and express CPAN dependencies (prereqs) for your module upon authoring modules.
CPAN distributions do not need to switch to
cpanfile, but you can certainly manage the dependencies in
cpanfile, then export them into
META.json files when shipping to CPAN, using tools such as Dist::Milla or Module::Install::CPANfile
Here are some of the reasons that motivates the new cpanfile format.
- Not everything is a CPAN distribution
First of all, it is annoying to write (a dummy)
Makefile.PLwhen what you develop is not a CPAN distribution, just so that installation like
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 cloud infrastructure), because it requires you to often commit the META file or
inc/directory (or even worse, both) to a repository when your build script uses non-core modules such as Module::Install or File::Copy::Recursive.
Many web application frameworks generate a boiler-plate
Makefile.PLfor dependency declaration and to let you install dependencies with
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 cpanfile, dependencies can be installed either globally or locally using supported tools such as cpanm or Carton. Because
cpanfilelists all the dependencies of your entire application and will be updated over time, it makes perfect sense to commit the file to a version control system, and push the file for a deployment.
- More control for the dependencies analysis
One of the limitation when I tried to implement a self-contained local::lib library path feature for cpanminus was that the configuration phase runs the build file as a separate perl process, i.e.
This makes it so hard for the script to not accidentally load any modules installed in the local
site_perldirectory when determining the dynamic dependencies. With the recent evolution of CPAN installer ecosystem such as local::lib support, it makes things much easier if installers figure out whether dependencies are installed, instead of by build tools such as Module::Install.
- Familiar DSL syntax
This is a new file type, but the format and syntax isn't entirely new. The metadata it can declare is exactly a subset of "Prereqs" in CPAN Meta Spec.
The syntax borrows a lot from Module::Install. Module::Install is a great way to easily declare module metadata such as name, author and dependencies. cpanfile format is simply to extract the dependencies into a separate file, which means most of the developers are familiar with the syntax.
- Complete CPAN Meta Spec v2 support
cpanfilebasically allows you to declare CPAN::Meta::Spec prerequisite specification using an easy Perl DSL syntax. This makes it easy to declare per-phase dependencies and newer version 2 features such as conflicts and version ranges.
First of all, most distributions on CPAN are not required to update to this format.
If your application currently uses
Makefile.PL etc. for dependency declaration because of the current toolchain implementation (e.g.
cpanm --installdeps .), you can upgrade to
cpanfile while keeping the build file based installation working for the backward compatibility.
If you are an author of CPAN module and want to manage CPAN module prerequisites using
cpanfile you can use one of the following tools:
Dist::Zilla::Plugin::Prereqs::FromCPANfile provides a way to merge dependencies declared in
cpanfileinto META files as well as build files. You can combine them using other prerequisite scanners like
Module::Install::CPANfile provides a
cpanfileDSL that reads
cpanfileto merge prerequisites when dumping
MYMETAfiles upon installation.
Build.PLwhen dumping out MYMETA information.