Bill & Ted's Bogus Journey
Most operating systems have a version of libpng, the library for reading and writing the PNG (portable network graphics) image format on them. Unfortunately, though, the libpng is often fairly old.
I wrote a CPAN module which links against libpng, but then trying to get the module tested with CPAN testers, a lot of bugs would happen. It was frustrating because I couldn't work out what was going wrong with the tests unless I could find out what version of libpng was installed on the testing machine.
The solution I came up with in the end was a bogus test file which merely prints the libpng version as its skip_all message. This turned out to be quite effective in working out what is going wrong as various improvements to my PNG module turn out to trip bugs in older versions of libpng.
Perl user since about 2006, I have also released some CPAN modules.
Yeah, I've seen in quite a few distributions the first test file will print out version numbers of dependencies. CPAN Testers will usually include version numbers of dependencies as part of their report, but that will not generally include optional dependencies and non-Perl dependencies (such as libpng in your case).
Using
skip_allisn't the only option though. Test::More includes a helpfuldiag()function for TAP-safe output. Then you can just have a simpleok(1); done_testing();at the end.Does the diag() output always show up in the CPAN tester output? That was the basic problem for me, I couldn't reliably get the version number of the remote machine without the skip_all trickery. Different CPAN testers use different testing modules, and this "skip_all" was the only thing I think I found which worked every time.
I went through the old versions of the module and it seems to have been around 2014 that I did this, after a burst of test versions of the module. I recently did another set of testing versions for some changes related to being able to alter compression and add international text to the PNG, and having a definite, known version for each testing machine was a huge help in simplifying things.
I used to do something similar, but now I pay more attention to whatever CI system I'm using. I'll print a bunch of diagnostic stuff in the setup/install phase.
There's a lot of variation in how CPAN testers have their machines set up, so I can't say for sure if there's any way of getting output from them which will always work, but it seems to work pretty reliably.
That said, in most of my distributions, I set the minimum version of Test::More as 0.96, so if people are using versions older than that, I don't have much experience of whether their output may differ.
(Why Test::More 0.96? It brought nicer behaviour to subtests; it or newer has been bundled with Perl since 5.13.4; it can be installed on Perls as old as 5.6.)
All of my CPAN modules were set up to be installed at CPAN so they mostly don't install from github, and unfortunately the stupid name I picked for my build module got used by someone else for an actual CPAN module, so I can't even release that to CPAN. I am currently thinking about what to do about that. "My very own" web framework/build system/whatever seems to be the curse of Perl.