I have added a conditional to exit FullAuto Install cleanly when a
needed module is missing, cannot be "default" auto-installed via CPAN
or CPANPLUS, and $ENV{'AUTOMATED_TESTING'} is detected.
ALL modules are installed via CPAN or CPANPLUS, but some require
shutting off the 'make test' and other manipulations to get them to
build and/or install.
That appears to be what you're objecting to.
For instance, the IO::Pty module has tests that fail in Cygwin/Windows -
even thought the module itself works perfectly in this environment. I
*TRIED* numerous times to get the author to fix this - even submitting
a patch that WAS actually included in a build (after about three months
of waiting). But then in the very next version, the fix was excluded
(probably due to poor version management) and I was back to square one.
Again it took MONTHS before the fix was applied, and the fix was only
available in one version, and for only a few weeks before it went
missing in the next release of IO::Pty.
I am willing to work with other authors, and have made attempts to
contact them. But I've gotten poor responses and long delays. I'm not
blaming them - for this is very nature of Open Source. Bottom line, if
you don't like something, fix it "yourself".
So I did - temporarily until the authors of the included modules get
around to, or eventually gather enough incentive to, make the necessary
repairs.
Two other modules that go beyond default build procedures as supplied
by Module::Build or ExtUtils::MakeMaker are BerkeleyDB and JSON. JSON
inappropriately asks the user for an option in such a way that it can
only be automatically included by temporarily manipulating the CPAN
environment variables. Obviously this is not "supported" - but my
options are limited.
BerkeleyDB requires an installation of Berkeley DB. "That" requires a
lot more than is offered by perl module utilities.
I really want people to try and use "Net-FullAuto", but if they can't
install it relatively easily, there is no way that is going to happen.
I've even toyed with the idea of just including their code in Net-
FullAuto's code base, but decided that was NOT an acceptable solution.
On a naked host, FullAuto and all it's dependencies can take well over
an HOUR to install. I simply can't have third party modules hard-
stopping that installation with options that will only confuse most
potential FullAuto users, or dying from fragile tests that are
returning false negatives (at least from FullAuto's perspective).
Most of these "false negatives" are occurring on Operating Systems that
the authors probably never tested on - like Cygwin/Windows, which is
REQUIRED for FullAuto to work on Windows.
I am open to any other suggestions you might have.