Buildable, Testable, Installable Git repo for Perl modules
tl;dr We might need a standard build file to build a module from Git repository, especially for the ones using Module::Install or dzil.
When an author of CPAN module uses an authoring tool that generates build files when shipping them to CPAN, the git repository usually doesn't have enough files to build, test and install the module.
For example, if dzil (Dist::Zilla) is used, the repository only conatains
dist.ini and there's no
Build.PL so standard CPAN installers or Continuous Integration tools don't know how to run tests on it.
Similarly, when Module::Install is used, the repository usually contains
Makefile.PL but not
inc/ directory, which usually results in:
Can't locate inc/Module/Install.pm in @INC ...
Why it is important
Installing a git repo instead of CPAN dist
As the requirement for fixed versioning in CPAN dependencies grow, users want to lock the versions of their CPAN module dependencies, using tools like Carton. It would be extremely useful if a developer can temporarily fork the module in question on github and then point to the fork, until the fix has been submitted to and merged in the upstream on CPAN.
This would allow something like the following in
requires 'Plack', '1.001', at => 'git://github.com/tokuhirom/Plack.git'
Testing a git repo
Continuous Integration tools such as Jenkins or Travis CI need some information to prepare the dependencies of the module to properly test it. Travis CI has before_install hook to specify in
.travis.yml so that the dependencies can be installed. But its format (and filename!) is very specific to Travis CI - it would be nice if it can be shared with Jenkins plugins and CPAN testers (wouldn't it be nice if you can feed your github master to the cluster of CPAN smokers?).
In case of Module::Install, the only problem is to bootstrap Makefile.PL without having
inc in the repository. Having the right set of modules (Module::Install, as well as its plugins) specified in the
develop section in
cpanfile would be enough to bootstrap the build.
cpanm might need a new mode/option to install
develop dependencies first, then
configure dependencies, before running
Makefile.PL to start building a module.
dzil is a little bit more complicated.
One options is to have something similar to
.travis.yml to specify the configure, build, test process without using the standard
Makefile.PL/Build.PL process, but without being specific to Travis CI.
The other would be to specify the "pre-build" command, such as
dzil build to create a standard CPAN-style distribution, then proceed like a normal CPAN module.