in reply to Unable to release modulino to CPAN

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.
I'm pretty confident that it is something to do with the file in the bin directory, which is quite short:

#!/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

Replies are listed 'Best First'.
Re^2: Unable to release modulino to CPAN - still struggling
by hv (Prior) on Oct 31, 2022 at 19:58 UTC

    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.

[reply]
[d/l]

      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

[reply]

        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 suggestion was aimed precisely at letting you mimic a situation similar to that on the testers' machines, at least for the scenario described in your excerpt.

        Did you try running the testsuite with the setup I suggested? You should at least be able to show that it would have highlighted the one problem you already found and fixed.

        If there are other failure modes you want to test for, you will first need to identify those.

[reply]
Re^2: Unable to release modulino to CPAN - still struggling
by pryrt (Abbot) on Oct 31, 2022 at 19:14 UTC
    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.

[reply]

      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

[reply]
        The second [problem] is how to test any solution on my machine.
        and
        in the hope that I will be able to test on my machine

        So the situation you need to try to replicate is having a different perl earlier in the path. So on your machine, have a fake directory with an executable file called "perl" that just dies with FAKE PERL or similar. Then put the path to that fake perl earlier in your path than your normal perl. Then run your /path/to/real/prove -l t/ with the full perl path, and when the test suite tries to run the fake perl instead of $^X , it should obviously fail.

        edit: as hv pointed out here simultaneous to my post, that is exactly what this post was doing for you: it created a fake perl "executable" (bash script) in your t/ directory, then added that t/ directory to the start of your path; when you run your test suite in that condition, your test script (assuming it still runs perl BLAH rather than $^X BLAH ) would fail.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom