Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

CPAN Dependencies rocks! (and release automation upgrades) 14 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • What is this short-sightedness of Test::Pod to try and declare it's own plan automatically of which you speak? Maybe I'm missing some cool functionality doing it the following way, but it seems to work well enough for me.

    if (!$ENV{PERL_AUTHOR_TESTING}) {
        plan skip_all => 'PERL_AUTHOR_TESTING environment variable not set (or zero)';
        exit;
    }

    eval qq{use Test::Pod};
    my $has_test_pod = $@ ? 0 : 4;

    eval qq{use Test::Pod::Coverage};
    my $has_test_pod_coverage = $@ ? 0 : 4;

    my $pod_test

    • It's all fine at THAT point... then when you call all_pod_tests_ok, or whatever the function is, Test::Pod will declare ANOTHER plan, and boom multiple plans explosion tests fail.

      • Don't do that, then.

        Use pod_file_ok and spell it out longhand. My latest thinking on the matter looks something like this [mongueurs.net], which I think is on the right track, although I'm still not happy with the redundancies in, for instance, $test_pod_coverage_tests and @coverage.

        • There's no way in hell I'm going to maintain 156 versions of the same pod testing script, written out longhand.

          The entire point of the short versions is to have one simple script I can have my release automation automatically copy into place as it's building the release distribution.

          Manually maintaining it all would be a massive waste of my time.

          • Do what I do, use the testpod and testpodcoverage or equivalent targets of your favourite installer module, and include an inert sham to fool CPANTS into thinking you have test files for these things.

            • Use the targets?

              I have no control over that either... CPAN Testers run what they want to run...

              Also, as far as I'm aware, there is as yet no target for "testperlminimumversion".

              Plus I have a hacked POD tester that includes support for the upcoming "begin block titles" that I wrote for Test::Inline and that Allison has said she'll add to Pod::Simple for a year now.

              And I refuse to do sham things just to shameless exploit CPANTS.

              • Ah. My approach is for authors who only want to run their author tests themselves. If you want the CPAN Testers to run your author tests, then you will have to write them as test files.

                I have no issue gaming CPANTS because I do run POD and POD coverage tests as part of the release process, which I believe makes me entirely eligible for those Kwalitee point.

                • I never run author tests.

                  They get run by my release automation, and they get run by CPAN Testers, but it would be a waste of my time to run them myself.

                  Ruthless automation and intentional ignorance of non-critical issues is the only way to deal with large numbers of modules.

                  • Irrelevant arguing about semantics. What you do on your own machine is completely inconsequential to my point. Your release automation could run the targets just as well as it runs the author tests.

                    The question is whether you want CPAN Testers to run POD and POD coverage tests. If you do, they need to be test files. If you do not, you can use the targets instead.

                    • Indeed I do want them to run them.

                      It's useful for uncovering unexpected weird cases.

                      Additionally, having them as test scripts makes sure that the next person that takes over my modules (presumably starting from a tarballs) CONTINUES to run the tests.

          • Manually maintaining it all would be a massive waste of my time.

            Oh yeah, I forgot that you do have quite a number of modules, don't you :) I guess I'm not playing in the same league.

            Still, could this not be driven by extracting candidats from MANIFEST? Looking for all .pm files under lib or the base directory of the unpacked distribution?

            • I also auto-generate the MANIFEST :)

              An Example Module in my SVN Repository [svn.ali.as]

              The only two files that I need in the root of my CPAN modules in the repository are Makefile.PL and Changes, which hold actual canonical information.

              The rest can be derived (yes I know I shouldn't use pod2man for README files, but I don't have anything better yet).

            • Oh wait, you mean that a different way.

              That's what the all_pod_tests_ok type methods in Test::Pod and such do, they do a scan for files, create a plan based on the number of files, then test them

              • Yes, precisely that. Something like:

                my @file;
                if (open my $MAN, '<', 'MANIFEST') {
                    while (<$MAN>) {
                        chomp;
                        push @file, $_ if /\.pm$/;
                    }
                    close $MAN;
                }
                else {
                    diag "failed to read MANIFEST: $!";
                }

                ...

                SKIP: {
                    skip( 'Test::Pod not installed on this system', scalar(@file) )
                        unless $test_pod_tests;
                    pod_file_ok($_) for @file;
                }

                But I don't know how

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.