Post without Account — your post will be reviewed, and if appropriate, posted under Anonymous. You can also use this link to report any problems registering or logging in.

CPAN Build issues

  • 4 Replies
  • 1370 Views
*

Offline Phil

  • Global Moderator
  • Sr. Member
  • *****
  • 437
    • View Profile
CPAN Build issues
« December 25, 2017, 12:48:12 PM »
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:

  • Quote
    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.
  • Quote
    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
    Quote
    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.
  • Quote
    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?
  • Quote
    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:
    Quote
      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.
« Last Edit: September 13, 2018, 01:37:08 PM by Phil »

*

Offline Phil

  • Global Moderator
  • Sr. Member
  • *****
  • 437
    • View Profile
Re: CPAN Build issues
« Reply #1: December 25, 2017, 01:04:54 PM »
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,
Quote
  > 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.
« Last Edit: September 13, 2018, 01:40:20 PM by Phil »

*

Offline Phil

  • Global Moderator
  • Sr. Member
  • *****
  • 437
    • View Profile
Re: CPAN Build issues
« Reply #2: September 13, 2018, 01:44:30 PM »
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.

*

Offline Phil

  • Global Moderator
  • Sr. Member
  • *****
  • 437
    • View Profile
Re: CPAN Build issues
« Reply #3: November 02, 2018, 10:25:34 AM »
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.

*

Offline Phil

  • Global Moderator
  • Sr. Member
  • *****
  • 437
    • View Profile
Re: CPAN Build issues
« Reply #4: November 27, 2018, 11:57:14 AM »
I have moved the README file back to the root. This is to shut up Kwalitee's complaint about "no README file". I also changed the "bugtracker" entry format in Makefile.PL to see if this will now point CPAN Issues to GitHub ticket system instead of the RT ticket system.
« Last Edit: November 30, 2018, 01:05:43 PM by Phil »