At least, App::ipchgmon 1.0.2 has entered your CPAN directory. This means that anything you want to upload must have a new (higher) version number.

I can't make sense of the missing Module::Pluggable prerequisite, as that is listed indirectly through your prerequisites, and even less of the DateTime prerequisite, as you list that one directly.

You also have a NAME section in your POD, but your package name in App/ipchgmon.pm is:

package ipchgmon;
[download]

I think that CPAN / MetaCPAN expect App::ipchgmon there - that may be the cause.

You are perfectly correct about the package naming issue. I have made the changes (including the tests) and the upload has worked without the failure email. Whether the testers will still have problems remains to be seen, but if so, you have at least enabled me to remove one problem.

Thanks and regards,

John Davies

What is this all about?

#!/usr/bin/perl
use strict;
use warnings;
use FindBin qw($RealBin);
use File::Find;
use feature 'say';

find ({wanted =>\&wanted, follow => 1 }, ($RealBin . '/..', @INC));

sub wanted {
    if ($File::Find::name =~ m/App\/ipchgmon.pm$/) {
        # Changed from "perl" to "$^X" per Slaven Rezic's advice
        # in issue 144972. I wouldn't have got near this issue
        # on my own. Many thanks, Slaven.
        my $cmd = join " ", $^X, $File::Find::name, @ARGV;
        say qx($cmd 2>&1); 
        exit;
    }
}
[download]

Why aren't you using

#!/usr/bin/perl

use App::ipchgmon;

App::ipchgmon::run();
[download]

Of course, you'll need to move the top-level stuff into run, and fix the incorrect package name in the module.

This is an attempt to ensure that the same code is called in the same way whether during developer testing, installation testing or production. I am trying to avoid anything like your App::ipchgmon::run line, as that would mean moving the option parsing out of the modulino. I understand StevieB's recommendation about having the invoker, POD and module as separate files, but I don't like it as I have the scars from separating them. If I knew enough about all the operating system issues, I'd prefer to change this to a simple link to the modulino, but I don't think I could do it in an OS-agnostic way for Windows and Linux, let alone others I don't use. But I'll happily listen to help and advice.

Regards,

John Davies

This is an attempt to ensure that the same code is called in the same way whether during developer testing, installation testing or production

It has no such benefit over the code I posted.

If anything, the fragility of your approach has the opposite effect of the one that's desired.

App::ipchgmon::run line, as that would mean moving the option parsing out of the modulino

You just said you wanted to use the same approach everywhere, so that's a good thing. The script calls run. The modulino calls run. You get the same code both ways.

But why are you using a modulino at all? You just said you wanted to always call the code in the same way. But making it a modulino does the exact opposite of that. It gives you two ways to use the module, and two ways of running the tool.

I'd prefer to change this to a simple link to the modulino

Why??? Hacks upon hacks for no benefit.

I'm posting this as a follow-up to my original post as the original problem is listed there. Corion has got me past the first hurdle to the point where the modulino is indexed on CPAN and I have cleared up one minor issue. But the major issue of the test failures remains. The problem space has been narrowed down by Slaven Rezic (is he a Monk? If you read this, Slaven, many thanks) in issue 144972 (https://rt.cpan.org/Public/Bug/Display.html?id=144972). Excerpts:

The test suite is failing on systems where the perl used for the current build is not the first perl in path... Probably at some point $^X should be used to call the correct perl.

#!/usr/bin/perl
use strict;
use warnings;
use FindBin qw($RealBin);
use File::Find;
use feature 'say';

find ({wanted =>\&wanted, follow => 1 }, ($RealBin . '/..', @INC));

sub wanted {
    if ($File::Find::name =~ m/App\/ipchgmon.pm$/) {
        # Changed from "perl" to "$^X" per Slaven Rezic's advice
        # in issue 144972. I wouldn't have got near this issue
        # on my own. Many thanks, Slaven.
        my $cmd = join " ", $^X, $File::Find::name, @ARGV;
        say qx($cmd 2>&1); 
        exit;
    }
}
[download]

Line 15, in the earlier versions, used perl instead of $^X and I hoped that this change would solve the missing modules problem. It doesn't. So I now have two problems. The first is how to use the "correct" perl. The second is how to test any solution on my machine. The only way I have is to upload and wait for the error reports, but this isn't the job of the CPAN testers. It's mine. Any advice on how to do that job would be greatly appreciated.

Regards,

John Davies

The second [problem] is how to test any solution on my machine.

If I understand you correctly, the thing you want to test is "if there is another perl earlier on the path than the one I am being built with, it has not been called". So mimic that scenario:

% cat t/perl
#!/bin/bash
echo "Wrong perl"
exit 1
% perl -E 'say "ok"'
ok
% PATH=`pwd`/t:$PATH \
    perl -E 'say "ok"'
Wrong perl
% PATH=`pwd`/t:$PATH \
    /usr/bin/perl -E 'say "ok"'
ok
%
[download]

You could also have the wrong-perl script touch a file, in case something invokes it and ignores both its output and its exit code.

I may not have explained my problem adequately. On my machine, everything works. It's on the testers' machines that I have a problem and I don't know if there is a simple way to mimic what they are doing that causes the test failures. My reading indicates that this could be done my setting up an entire virtual machine to act as a pre-release test environment, but even then I would have to set it up in such a way that it would generate the errors, and not all test runs return errors. It also seems like a very large yak to shave unless there is no option.

I get it now. Apologies for my earlier stupidity - it's amazing what a night's sleep can do. I was misunderstanding the bash (I default to Windows) and getting a totally false impression. I have implemented a Windows version of your code & I think it does what I need.

Regards,

John Davies

Since the problem in that report was with t/00-modulino.t, did you check that for external perl calls? Like the invocation string in L14?

You will want to audit all your tests for such invocations, just to make sure.

Thanks; you may well be right. I had ignored that aspect. I'll try that out but will wait before uploading in the hope that I will be able to test on my machine before wasting the testers' time.

Regards,

John Davies