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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • So, not so clear what you need me to do (too little caffeine today). You want me to drop the Test::Pod stuff? Sorry, but that link you gave regarding author best practices it broken for me. Just let me know what to do and I will cut a release asap. John
    --
    Waiting on the Road to Eventually, I lost my Place On Line
    • In your Makefile.PL change..

      build_requires 'Test::Pod' => '1.14';
      build_requires 'Test::Pod::Coverage' => '1.08';

      ..to..

      recommends 'Test::Pod' => '1.14';
      recommends 'Test::Pod::Coverage' => '1.08';

      You already have the appropriate eval/skip in both respective test files.

      • okay, I'll do this today or tomorrow then
        --
        Waiting on the Road to Eventually, I lost my Place On Line
      • Actually, it shouldn't be in recommends either.

        Firstly, recommends isn't actually implemented.

        Secondly, once the META.yml upgrade process does reach the point of dealing with this, it's likely to mean either "Should be installed for all users except in resource-constrained environment" or possibly "Enhances the run-time functionality of the module".

        • Should there be a build_recommends then? Although I don't reference them in my Makefile.PL, I do reference them in the 'recommends' section of my META.yml. I'd rather mention them somewhere, in the event that someone might be interested :)

        • Well, That sucks. I changed it, tagged it and released it. "recommends" didn't give any errors when I ran perl Makefile.PL, and the rest. Now I have to go figure out what I need to change and change it again :(
          --
          Waiting on the Road to Eventually, I lost my Place On Line
    • 1. Remove all mention of the author test modules from META.yml

      2. As a bonus, you can change pod.t to something like this

      #!/usr/bin/perl

      # Test that the syntax of our POD documentation is valid
      use strict;
      BEGIN {
              $| = 1;
              $^W = 1;
      }

      my @MODULES = (
              'Pod::Simple 3.07',
              'Test::Pod 1.26',
      );

      # Don't run tests during end-user installs
      use Test::More;
      unless ( $ENV{AUTOMATED_TESTING} or $ENV{RELEASE_TESTING} )

      • Speaking of cargo-cult code....

        • It's good enough until Module::Install (and other things) have built in xt support

      • well, META.yml gets generated automatically, I guess you want me to editted manually? I guess I don't really get it, I just patterned my Makefile.PL against some other big distros, like DBIC, Moose, etc and just assumed they knew what that are doing.
        --
        Waiting on the Road to Eventually, I lost my Place On Line
        • You remove it manually from the Makefile.PL so it's removed automatically from the META.yml.

      • I realize you are only suggesting this for the pod tests.  For those tests, this is innocuous enough.  However, as chromatic pointed out, cargo cult programming exists.  I'd prefer to give the cargo cult programmers as few chances to happen across code that skips all tests for people installing via CPAN/CPANPLUS, especially since some of them may not run any tests on their own boxes (even though they have them.)

        • You prefer to prioritise the people that would copy and paste author tests into their own modules ahead of everyone everywhere that installs modules for any reason at all?

          That seems like prioritising a small group with a rare situation ahead of an enormous group with common situation.