You can't really declare binary dependencies.

In my modules, I make the tests check whether the external binary is available and otherwise skip the test. See for example helper.pm and t/47-mech-simplest.t in WWW::Mechanize::Chrome.

You can add appropriate system dependencies via CPAN::Plugin::Sysdeps, but I'm not sure how many CPAN testers honour this.

Thanks Corion. So all I can do is *for each* of my test files to first check if chrome is available (via your helper, e.g. https://metacpan.org/release/CORION/WWW-Mechanize-Chrome-0.71/source/t/helper.pm#L21) and skip all tests in that test file gracefully, so that the testers think that tests have been passed, albeit with a stderr message for the real users. Correct?

That is how I do it, but it may also make sense to simply skip the test using something like this:

use Test::More;

if( chrome_is_unavailable ) {
    plan skip_all => "Chrome / chromium not found/installed, skipping 
+test.";
    exit 0;
};

plan tests => $test_count;
...
done_testing();
[download]

If the dependency is necessary for your module to be usable at all, then check it is installed in Makefile.PL, and die if it's not found. That way, testers will bail out as soon as possible, before running any tests, and won't submit failure reports to the CPAN Testers service.

If the dependency is necessary for your test suite, but your module is still at least partly useful without it, then check it is installed in each test case that requires it, and skip the test if it's absent.

Your module in particular seems to belong to the first category.

I second what tobyink said: use die and BAIL_OUT as soon as needed.

I asked very similar question when I received just red failurs from (very old win32) smokers CPAN tester machines.

My Win32::Backup::Robocopy needs:

1) to just run on win32 systems
2) to have a robocopy.exe available, so..

..in the Makefile.PL both check are done and they use die to exit direclty the building phase.

3) the module also needs a valid and not bugged version of the executable, so in 00-robocopycheck.t I re-test both the persence and the validity of the executable (with the check_robocopy_version method provided by the /t/bkpscenario.pm module).

With the above now the module tester matrix is just full of unknown instead of failures. But the output is both useful for the tester or casual user and for me too:

# Linux output:
Output from '/home/perluser/perl5/perlbrew/perls/perl-5.34.1/bin/perl 
+Makefile.PL':

OS linux unsupported! at Makefile.PL line 9.
BEGIN failed--compilation aborted at Makefile.PL line 11.

# oldish win32 output:
Output from 'C:\Strawberry\perl\bin\perl.exe Makefile.PL':

robocopy.exe not found!  (you can set environment variable PERL_ROBOCO
+PY_EXE to a custom path)  at Makefile.PL line 40.
BEGIN failed--compilation aborted at Makefile.PL line 55.
[download]

..and no one reached the test phase, but if this happens and there is an invalid version of the needed executable we will both know, me and the user.

L*

I'm afraid to say so publicly, but I've been close to just relying on my own GitHub Actions based CI. Haven't committed to the idea yet but I'm close.

That Alien idea is alien to me. In Linux, with everything being installed (good practice dictates anyway) with the system package manager, I fail to see how writing this Alien module will be an easy task. OK, easier than installing from a tarball but you are essentially creating a perl interface to every package manager out there.

Bottomline, Perl modules must be integrated (even more, I know fedora offers perl modules - often outdated - via its package manager) to the system's package manager so that it understands modules' binary dependencies and installs them as it knows how to do best. But where does that leave perlbrew and the "don't mess with system perl"? dnf makes it very difficult to have parallel installations (e.g. older versions). But there exists the alternatives framework which could be used - I mean by the package manager. And perlbrew be integrated into this framework.

And so for a start, wouldn't it be easier for authors if ExtUtils::MakeMaker had also binary dependency checking with transparent, to the author, finding libs and executables? The perl facility (for discovering binaries, i think that's OK no?) is there. That can make the life of package-manager devs to dare some innovation in this field.

To be faire, perhaps, this is a rare case where lame windows can boast, because of Perl distributions are more centralised (from what I read here) and take over from windows, which invariably makes things better I guess.

Anyway, SankoR thanks for the stimulus to mumbling my random thoughts

Is that good practice? Unless there's some platform specific reason to install a perl module in my system perl, a containerized perlbrew install will always be safer than using system perl.

Like perlbrew, Alien's goal is to avoid updating or relying on system binaries or libs. When the system version of a lib/binary doesn't meet the module author's specific requirements, a local version is downloaded or built. If a module is written for one version of a lib, forcing an up- or downgrade of the system install of that lib/binary might bring the sky down on your head. Similarly, a system upgrade might break a perl module that isn't yet compatible with a more recent lib/binary. Having local dependencies separate from the system package manager will always be less complicated and disk space is cheap enough that having a separate perlbrew (that can be replicated, upgraded, deleted, etc.) and a 'stable' system perl that is unchanged from the upstream distribution won't break the bank.

Not all module authors use ExtUtils::MakeMaker so any functionality built only into it wouldn't work everywhere. Perl's package installation ecosystem is so fragmented that Alien (as much as I dislike the alienfile system that backs most of them) is the current best option to try and wrangle everyone into a single "Way" to manage binary dependencies. Maybe, one day, we'll have a single, proper module install system built and designed as a part of the core language spec like Rust's cargo/crate which has a way to define binary dependencies built in. Maybe cpanfile will continue to grow in adoption and become that.

Anyway, we're both in the right place for random thoughts. :)