On Wed Oct 03 04:51:55 2018, haarg wrote:
Show quoted text> On Tue Oct 02 21:33:05 2018, JKEENAN wrote:
> > This evening I attempted to build and test Tapper-Cmd. I satisfied
> > all prerequisites indicated by 'dzil listdeps' and 'dzil build'
> > operated as expected. However, 'dzil test' was graded FAIL because
> > of
> > failures in 3 test files.
> >
> > #####
> > $ dzil test
[snip]
Show quoted text> >
> > Test Summary Report
> > -------------------
> > t/author-eol.t (Wstat: 1536 Tests: 39 Failed: 6)
> > Failed tests: 11-12, 22, 24-25, 27
> > Non-zero exit status: 6
> > t/author-pod-coverage.t (Wstat: 512 Tests: 13 Failed: 2)
> > Failed tests: 4, 11
> > Non-zero exit status: 2
> > t/author-pod-syntax.t (Wstat: 256 Tests: 19 Failed: 1)
> > Failed test: 2
> > Non-zero exit status: 1
> > Files=16, Tests=220, 417 wallclock secs ( 0.09 usr 0.02 sys + 17.13
> > cusr 1.87 csys = 19.11 CPU)
> > Result: FAIL
> > Failed 3/16 test programs. 9/220 subtests failed.
> > Makefile:956: recipe for target 'test_dynamic' failed
> > make: *** [test_dynamic] Error 255
> > error running make test
> > #####
> >
> > In ordinary -- i.e., non-Dist-Zilla-based -- CPAN distributions,
> > tests
> > that only an author would run are generally excluded from the scope
> > of
> > 'make test'.
>
> You aren't running make test, you are running dzil test.
Graham, thank you for taking the time to read this bug report.
These days, when I'm working on a Perl Toolchain-ish project[1], I expect that I will usually find the source code on github.com and that the author/maintainers will accept pull requests for consideration. So I fork the official repo to my github.com page and then clone from there to disk. It is at that point that I observe how the library is structured. In this case, when I start work on Tapper-Cmd, I saw:
#####
[Tapper-Cmd] 538 $ ls -l
total 20
-rw-r--r-- 1 jkeenan jkeenan 3069 Oct 2 19:34 Changes
-rw-r--r-- 1 jkeenan jkeenan 261 Oct 3 09:18 dist.ini
drwxr-xr-x 4 jkeenan jkeenan 4096 Oct 2 19:34 lib
-rw-r--r-- 1 jkeenan jkeenan 1316 Oct 2 19:34 LICENSE
drwxr-xr-x 5 jkeenan jkeenan 4096 Oct 2 19:34 t
#####
I noted the presence of dist.ini. I'm not a fan of Dist::Zilla, so I groan a little[2]. But by now I've encountered this situation often enough to wonder, "Do the maintainers include a Makefile.PL so that I can play with the library without all the Dist::Zilla trappings?"
In this case, the answer is "No." And not only do I have a Makefile.PL -- I don't have a README or a CONTRIBUTING either! So, on the basis of prior experience, I grit my teeth and issue commands like:
#####
$> dzil listdeps | cpanm
$> dzil build
$> dzil test
#####
Show quoted text>
> > This can be effected either by placing them in a
> > directory such as 'xt/' which is not included in the 'test' make
> > target, or by setting them up to run only when an environmental
> > variable -- perhaps $PERL_AUTHOR_TESTING -- is turned on. Generally
> > speaking, a distribution's user would not expect to be running
> > "author
> > tests" and hence would not expect failures in "author tests" to
> > result
> > in a grade of FAIL which would preclude installation.
>
> These tests will not be run by users, because they are already
> conditional on
> the AUTHOR_TESTING environment variable. They are being run for you
> because
> the dzil test command enables the AUTHOR_TESTING environment variable.
> dzil
> is an author tool, users won't be using it. With a normal make test,
> these
> tests will skip themselves.
>
In the absence of a Makefile.PL, a README or a CONTRIBUTING, how am I to know about the AUTHOR_TESTING envvar? The string 'AUTHOR_TESTING' does not appear anywhere in the output of 'dzil test'.
I know there are other DZ-based CPAN distributions which, via one of the above files or otherwise, provide guidance to potential contributors like myself as to how to contribute without incurring the DZ overhead. Perhaps Tapper-Cmd should follow their example.
Show quoted text> >
> > Please re-examine how you have structured your test suite. I would,
> > of course, recommend getting the author-ish tests to PASS. But even
> > if they do PASS, they should not be run by an ordinary user.
> >
Thank you very much.
Jim Keenan
[1] In this case, the Toolchain-ish project is a search for opportunities to replace File::Slurp.
[2] I concede that for people who have to manage large numbers of CPAN distributions, Dist::Zilla is an appropriate tool. The Tapper project -- which I'm not really familiar with myself except from a CPAN-river dependency perspective -- appears to be such a project.
RT for rt.cpan.org