Convincing Dist::Zilla to use a different Pod::Coverage class

pokki has asked for the wisdom of the Perl Monks concerning the following question:

Hello dearest Monks,

At $work we use Dist::Zilla for all distribution management tasks. This mostly works, but I have issues with POD coverage tests.

First, I cannot find out how to specify a different Pod::Coverage subclass, e.g. Pod::Coverage::CountParents. The dzil plugin uses Pod::Coverage::TrustPod, presumably because that's how RJBS does it, and I can't find a way to change it. Have I missed something or should I file a feature request?

This is secondary, but it seems to me that just *running* the POD coverage tests is rather hard too. In my own non-dzil distributions, I would just run

prove xt/pod-coverage.t

With dzil, I have found only the two following methods:

```
dzil test --release
```
which also runs the whole test suite, whereas I'm just trying to see if I have finally finished updating the doc or if I missed a method somewhere
the cumbersome
```
RELEASE_TESTING=1 dzil run prove t/release-pod-coverage.t
```
which forces me to build the distribution once beforehand to check that the POD coverage test file is where I think it is

Since everybody says that dzil makes your life easier, I cannot believe I'm using it right. What did I miss?

Comment on Convincing Dist::Zilla to use a different Pod::Coverage class

Replies are listed 'Best First'.
Re: Convincing Dist::Zilla to use a different Pod::Coverage class by Corion (Patriarch) on Dec 15, 2014 at 14:52 UTC
There seems to be Dist::Zilla::Plugin::Test::Pod::Coverage::Configurable (found via Dist::Zilla coverage). I'm not in the camp of people saying that Dist::Zilla would make life easier. It seems to solve problems that I don't have, and it certainly creates problems for me, as I can't easily run tests for the repository checkout of a module modify it without buying into the Dist::Zilla mechanism myself.	[reply]
Re^2: Convincing Dist::Zilla to use a different Pod::Coverage class by pokki (Monk) on Dec 15, 2014 at 16:35 UTC
Aah, this looks exactly like what I need, at least for the POD coverage. I'm not in the camp of people saying that Dist::Zilla would make life easier. It seems to solve problems that I don't have, and it certainly creates problems for me, as I can't easily run tests for the repository checkout of a module modify it without buying into the Dist::Zilla mechanism myself. Yes, this is my general experience as well. It works fine as long as you're working exactly like the first person to write the dist.ini does, but it's not flexible enough to cover the rest of the use cases. For instance, using good old prove, plus TAP::Formatter::JUnit, I can emit JUnit XML and make Jenkins happy, but I can't figure how to use custom formatters with Dist::Zilla. Thanks for the save!	[reply]