There are some great notes there.
Nice solutions for OS requirements also.

It seems that if something is missing, you should exit in the Makefile.PL, that's what Devel::CheckLib suggests.

Some of it seems bulky, like checking os.. the use-devel-assertos script is iffy, but dammit it works.

Thank you so much, this is incredibly helpful.

It seems you can basically test these things in the Makefile.PL. If something is missing, you should warn and exit. There is a convention for bailing out on bad os, 'OS UNSUPPORTED' or 'No support for OS'- I'm trying to find out what the warning should be for a missing binary dependency, or lib, etc- per CPAN tester standards.

But my main question is answered, the tests should check the distributed code, not the system setup. The Makefile.PL should make decisions such as missing files, etc.. and should not die but exit with warnings if so.

If you've got any suggestions for how to improve the use-devel-assertos and use-devel-checklib scripts then do please let me know, either by email or by filing a ticket in RT.

$ perl Makefile.PL
Did not find GP/PARI build directory around.

Do you want to me to fetch GP/PARI automatically?

  (If you do not, you will need to fetch it manually, 
   and/or direct me to the directory with GP/PARI source
   via the command-line option paridir=/dir)
[download]

All I can do is throw an exception and exit if something is missing, or notify and continue.

What I would do is have the test code check to see if something is missing and then use Test::More's "skip" feature to skip any tests that depend on the feature.

I realize this isn't what you regard as The Right Way, but I think it works tolerably well. I think it would be pretty difficult for the build process to cover every sort of system feature that you might be interested in checking.

(I see that if I have to skip all of the tests, the smoketest machines mail me UNKNOWN messages instead of FAIL... seems reasonable, off hand).

If anyone's interested, I've been writing test code that looks like:

use Test::More;
my $emacs_found = qx{ emacs --version 2>/dev/null };

if( not( $emacs_found ) ) {
  plan skip_all => 'emacs was not found in PATH';
} else {
  plan tests => 27;
}

use_ok( 'Emacs::Run' );

[...]
[download]

Hahahah.. yeah.. you sly dog you... that's very tempting :-) But it will blow up on non unixy systems, right? If so, you should bail out unless the os is all good. Unless you don't care about those systems, but then you get ugly test reports.

I think I'm having feelings for Devel::AssertOS , it has a cli tool to embed the junk in your distro very quickly. I find it ingenious.

It just adds some inc stuff into your distro, appends the MANIFEST, and prepends the Makefil.PL with use lib inc; use Devel::AssertOS qw(Unix Otherstuffyoutellit);

I suppose after that we can go ahead and do whatever.. invoke external bash scripts.. backtick.. etc. Some systems might have security features to disable a cpan install from making command calls ???

But it will blow up on non unixy systems, right? If so, you should bail out unless the os is all good. Unless you don't care about those systems, but then you get ugly test reports.

Actually, I'm not sure about how big an issue this is at this point. Most of the "windows" boxes that perl runs on are likely to really be "cygwin", and MacOS is essentially the latest proprietary fork of the BSD codebase. As far as smoketest messages go, I'm sorting through too many other ugly messages to even notice if there's a VMS system out there complaining about something.

(Though it occurs to me now that I write this that I should really be trapping any errors on that qx, and also skipping the tests if it blows up. Easy enough.)

Still, I'll take a look at Devel::AssertOS... the last time I tried to think about issues like this was some years ago, and there definitely seemed to be some missing pieces in the story. Like, you could check $^O, but you had to parse the results yourself, and you needed to watch out for gotchas (e.g. you can't just match for "win" if you want to skip windows boxes, because that'll also hit other things like "cygwin"... so you might, wonder, what's the definitive list of all possible returns from $^O? Last I looked, there didn't seem to be one...).

Alien is a horrible namespace choice. Yes I know it's been approved by Brian DFoy (cpan dungeon master) and his minions.

I think Damian Conway (perl feng shui master) would not approve. Namespaces should be descriptive. Could have been 'Notperl'.. who knows.. Alien?! Eek!

I think the 'Alien' concept stinks like system maintenance. I think this kind of thing is likely to work only on posix systems, and then.. there are better ways to install things if they are missing. I would be sketched out about having perl hacks to detect if you have things like rpm and yum. Yes, not that Alien decrees that.

By what I see of the Alien concept, you would have a Alien::MySQL which would detect if you have mysqld, mysql-devel mysql-client.. who knows--- before you install DBD::mysql.

It seems to me that detection is plenty help already. After that, it seems the likely people to be installing non-perl libraries would be admins. Yes, I know.. users can too.. Pfffttt.. users...

Users installing non-perl resources should probably not be given a perl hack to help them out with it ?

Like they say, if you think you can do better ...