Even if I know most about testing and I know about prove and yath, my usual start is always the same:
- Get the dist
git clone / cpan + get / get the tgz
- Prepare
$ cd Module-dir
$ perl Makefile.PL
If it complains about no Makefile.PL, curse loudly, check if there is a Build.PL
$ perl Build.PL
If there is no Build.PL either, curse even louder and ask myself the question if applying my patch is worth the trouble. If not, just give up.
- Test
$ make test
If it complains about missing Makefile, curse again and try Build.PL
$ perl Build test
If I really cared enough, and installed enough of dzil
$ dzil test
If that still complains about yet another missing plugin, give up and remove the dist dir: My time is valuable too.
- Hack
If this module now passes all tests, check if my change still applies. (It might have been fixed in the git repo already).
Otherwise, make the change, make a test case, update ChangeLog (or any other legal name) and submit a PR.
Even as a seasoned perl programmer with enough knowledge to get the ball rolling, I see plenty of decision points where
I would decide to leave the annoyance/bug to what it is and maybe just add an issue, which in most cases is much easier than
going through the installation of dependencies I won't need for anything but this single module.
Enjoy, Have FUN! H.Merijn
| [reply]
[d/l]
[select] |
| [reply] |
At least for installing the prerequisites, and if the author uses Pod::Weaver, even a docpatch can't be applied by the module maintainer well.
| [reply] |
