I'm fully covered
There seems to be a new feature of showing the coverage in metacpan. Fortunately I have already achieved 100% coverage here:
https://metacpan.org/release/Acme-Include-Data
Some other places are not so fortunate.
http://cpancover.com/latest/JSON-Repair-0.07/blib-lib-JSON-Repair-pm--subroutine.html
I only have 33% coverage in my POD.
The thing is though that I deliberately didn't document these private routines.
I looked in vain through what documentation I could find for this coverage system
https://metacpan.org/pod/Pod::Coverage
to find out how to tell it that these routines were never meant to be documented, but couldn't find anything except for a regular expression which ignores routines with a leading underscore.
Can anyone tell me how to tell the coverage meter to not measure these routines?
Perl user since about 2006, I have also released some CPAN modules.
Form the Pod::Coverage POD
also_private
also_private items are appended to the private list
as well as this one
https://metacpan.org/pod/Pod::Coverage::TrustPod
That's OK if I am using it on my own computer, but
how can I use that to tell the thing linked from metacpan.org that these are private routines?
Rename the subroutines. Add an underscore at the beginning and they will be ignored.
Perhaps if I tied a piece of purple string to my module it would work also. Or maybe I need to burn incense at half past midnight in front of a statue of Theresa May.
Is there some way of informing this coverage system without having to do stupid things like putting underscores all over the place?
These routines aren't exported, and they aren't methods, so there's no reason for this module to claim that they're not documented.
In my opinion, marking private subroutines with a leading underscore is a de facto standard in the perl world. So, independently of the coverage issue, it would be a good thing to do.
From a more general point of view I think there could be several reasons to change the way how the coverage is generated.
For example, in one of my modules I have an optional "dependency" (*), and if it is not installed, the corresponding code is not called and therefore not covered, so I am never able to get 100% coverage, unless I can tell the coverage generator to install certain modules.
For other modules you would need a database server, so these modules cannot get a good coverage either. In that case it might be better to not show any coverage data on metacpan at all.
(*) In YAML::PP, one can choose between JSON::PP::Boolean, boolean.pm and just perl 1/"", so I don't want to mark the two modules as a dependency.
You might document the private methods...
That's ingenious, and if I was desperate to remove these things I would do that, but it seems to mean more complications in terms of having to maintain a bit of otherwise-useless documentation to fool the coverage system.
That would be a fair stance to take if we were talking about CPANTS, whose purpose is explicitly to be opinionated about best practice, because the proviso is that its score is only an indicator and not always correct or applicable – as it says, it measures kwalitee but not quality. In my view it is terrible for MetaCPAN to be dogmatic in the same way and it’s quite terrible to lose the kwalitee/quality distinction. Just because something doesn’t match somebody else’s personal fashion doesn’t make it wrong.
All of the coverage stats are generated by cpancover.com MetaCPAN is only returning the results provided by the cpancover API.
It doesn’t make any difference to users whether MetaCPAN runs the coverage checking itself or endorses the data generated by another service. The weight given to the data by MetaCPAN is the same.
Yes, metacpan is advertising these coverage results on their web site.
For whatever reason, the coverage results are appearing inconsistently:
https://metacpan.org/release/Table-Readable
has no link but it's here:
http://cpancover.com/latest/Table-Readable-0.03/index.html
There are quite a lot of these glitches in the links, which don't seem to be formed correctly in many cases.
Some of the coverage ratings seem to be useful but other ones seem to be not there yet, like the Pod coverage or the coverage of XS macros:
http://cpancover.com/latest/JSON-XS-4.0_00/XS-xs--branch.html