[Phil]

I always try to get a nice clean CPAN upload, so that PDF::Builder looks good to someone browsing it in CPAN. Sometimes a minor POD error will slip through, for which I will not necessarily submit a new upload (version). However, I will fix the problem in GitHub so that it should be clean next time.

There are a few persistent things in CPAN, particularly the "Kwalitee" report, that are causing concerns:

• Kwalitee Indicator: buildtool_not_executable <core>
  
  The build tool (Build.PL/Makefile.PL) is executable. This is bad because you should specify which perl you want to use while installing.
  
  How to fix
  
  Change the permissions of Build.PL/Makefile.PL to not-executable.

  Um, OK, what exactly are they asking for here? Are they saying that the Makefile.PL I supply is bad because it's executable on a Linux system? It's created on a Windows system, so I don't have any control (that I know of) of permissions when it gets on to the CPAN system. If you build on a Linux box, do you make sure the file is 644 and magically this error goes away? On my system, I have the .pl file extension associated with "perl", so I don't have to type in "perl" on the command line. Is that "executable" being passed to the CPAN build? I'll have to remember to check at an intermediate stage, whether Makefile.PL has its permissions explicitly stated somewhere, and if that's something I can change (e.g., "1755" -> "1644").
  
  By the way, Kwalitee's error labels are stupid. They should state what the error condition is, not what the fix is! So this one should be buildtool_is_executable.

• 1 Extra Issue
  
  use_warnings
  
      Add 'use warnings' (or its equivalents) to all modules (this will require perl > 5.6), or convince us that your favorite module is well-known enough and people can easily see the modules warn when something bad happens.
  
      Error: PDF::Builder, PDF::Builder::Annotation, PDF::Builder::Basic::PDF::Dict, PDF::Builder::Basic::PDF::File, PDF::Builder::Basic::PDF::Filter::FlateDecode, PDF::Builder::Basic::PDF::Filter::LZWDecode, PDF::Builder::Basic::PDF::Literal, PDF::Builder::Basic::PDF::Page, PDF::Builder::Basic::PDF::Pages, PDF::Builder::Content, PDF::Builder::Lite, PDF::Builder::NamedDestination, PDF::Builder::Outline, PDF::Builder::Page, PDF::Builder::Resource::BaseFont, PDF::Builder::Resource::CIDFont, PDF::Builder::Resource::CIDFont::CJKFont, PDF::Builder::Resource::CIDFont::TrueType, PDF::Builder::Resource::CIDFont::TrueType::FontFile, PDF::Builder::Resource::ColorSpace, PDF::Builder::Resource::ColorSpace::DeviceN, PDF::Builder::Resource::ColorSpace::Indexed, PDF::Builder::Resource::ColorSpace::Indexed::ACTFile, PDF::Builder::Resource::ColorSpace::Indexed::Hue, PDF::Builder::Resource::ColorSpace::Indexed::WebColor, PDF::Builder::Resource::ColorSpace::Separation, PDF::Builder::Resource::ExtGState, PDF::Builder::Resource::Font, PDF::Builder::Resource::Font::BdFont, PDF::Builder::Resource::Font::CoreFont, PDF::Builder::Resource::Font::Postscript, PDF::Builder::Resource::Font::SynFont, PDF::Builder::Resource::UniFont, PDF::Builder::Resource::XObject::Image::GD, PDF::Builder::Resource::XObject::Image::GIF, PDF::Builder::Resource::XObject::Image::PNM, PDF::Builder::UniWrap, PDF::Builder::Util
  

  Many modules still use "no warnings" with a list of what I presume are exception conditions. For instance, Builder.pm has
  

  use strict;
  no warnings qw[ deprecated recursion uninitialized ];

  Is it asking me to stick use warnings; before no warnings? Would "warnings" then be the default condition, with a few specific conditions to be ignored? Or do I need to do some major fixes to the code so that "no warnings" can be replaced by "use warnings"? I'm reluctant to change any code until I understand how these things are supposed to interact.

• Kwalitee Indicator: meta_yml_has_provides <experimental>
  
  This distribution does not have a list of provided modules defined in META.yml.
  
  How to fix
  
  Add all modules contained in this distribution to the META.yml field 'provides'. Module::Build or Dist::Zilla::Plugin::MetaProvides do this automatically for you.

  Since META.yml seems to be built on the fly, I don't think it will be easy (though not impossible) to insert some sort of additional content into the file. I use ExtUtils::MakeMaker to do the building, so is there a way to get the desired content into META.yml that way? If not, what exactly are they looking for — a list of every .pm file (and in what format), or something more manageable?

• Kwalitee Indicator: meta_yml_has_repository_resource <experimental>
  
  This distribution does not have a link to a repository in META.yml.
  
  How to fix
  
  Add a 'repository' resource to the META.yml via 'meta_add' accessor (for Module::Build) or META_ADD parameter (for ExtUtils::MakeMaker).

  This one I think I figured out. The next build, I'm trying the following in Makefile.PL:
  

    META_MERGE        => {
  
      "meta-spec" => { version => 2 },
  
      resources => {
  
        homepage => "https://www.catskilltech.com",
  
        repository => {
            type => 'git',
            url => 'git://github.com/PhilterPaper/Perl-PDF-Builder.git',
            web => 'https://github.com/PhilterPaper/Perl-PDF-Builder',
        },
  
      },
  
    },

  and hopefully this will add the repository information it wants to META.yml. I'll have to make a note to change my website when it goes https sometime soon (I hope).

Website is now https://www.catskilltech.com.

[Phil]

In each of my releases, I've managed to forget to properly handle a new prerequisite. It would be really nice to be able to do a private "test" upload to CPAN, to see if everything checks out clean, before doing the public upload under a new version number. In RT 123123,

  > If anyone knows a way to make a "test" or "trial" CPAN upload, where
  > some testing is done but the distribution is not made public (so I
  > don't waste a version number if something goes wrong), I'd appreciate
  > a pointer to the instructions to do this.

<from Andreas Koenig>
Frequently used for this kind of question: Travis.

Does anyone have some clear instructions for using Travis that they can point me to? I think the original PDF::API2 had some sort of "Travis" file, but I don't know how to use it (I recall that I was getting some errors before disabled .travis.yml by changing the name). Is Try Travis CI with your CPAN distributions a good start? Will it give me what I am looking for?

Of course, while the preliminary checkout is done pretty quickly, it takes a day or two for the testing to get going, and this is where missing prerequisites seem to bite me. Any suggestions for building on Windows (Win7 currently) and testing the resulting upload (especially for missing prerequisites and POD errors) would be appreciated.

Now on Windows 10.
I have disabled Travis for now because the last time I left the file name "correct", it apparently tried running Travis and I got ugly error messages.

[Phil]

Regarding the Kwalitee issues, there seems to be a lot of overlap with what perlcritic is reporting. Hopefully, fixing a lot reported by perlcritic (see pc.bat) will make Kwalitee happier. The "no warnings" issue alone will clean up a lot of both systems' complaints.

[Phil]

Starting in release 3.011, I added a line to Makefile.PL to direct bug reports from the CPAN RT system to GitHub. Unfortunately, it appears to have not worked. Some day I'll do some more research to see if I was given incorrect information.