[Nagiosplug-devel] Re: Perl plugins that fail gracefully by reporting missing modules.

[Awais Ahmad]

I thought they already failed gracefully :). I find the contents of @INC
being printed to STDERR pretty useful, so I wouldn't use eval {} in the
context being discussed myself.

BTW what performance hit? eval {} does not cause repeated recompilations
as eval STRING does. All eval {BLOCK} does is trap runtime exceptions.

Anyway since we usually don't need a plugin to execute hundreds of times
a second or/and crank out hundreds of millions of web pages a day, I
would consider the use of either forms of eval quite reasonable, at
least in the plugin context.



Awais Ahmad

   







On Sun, 2004-03-07 at 22:25, Paul L. Allen wrote:
> Stanley Hopcroft writes: 
> 
> > I am writing to suggest that Perl plugins can be made to fail gracefully
> > when the pre requisite modules are not found on the host.
> 
> But there are so MANY ways things can fail if clueless people are
> involved.  It is impossible to make things idiot-proof because idiots
> are so resourceful. 
> 
> > 1 the FAQ about especially /contrib plugins that
> > fail when Perl cannot find utils.pm in the standard Perl search paths.
> 
> It's a nice touch, if it doesn't compromise performance too much.  Other
> perl plugins do check for the existence of utilities they (and they alone)
> depend on.  But utils.pm is used by EVERY well-written perl plugin, so
> having them all check that it is loadable puts an unnecessary performance
> hit on all of them.  Once you first run the first perl plugin on a box
> you know if utils.pm is there or not and every subsequent run of that and
> every other perl plugin conducts an unnecessary check that utils.pm is
> there. 
> 
> > 2 distress when a plugin is put into production after testing in a
> > directory containing the prereqs and thereupon no longer has access to
> > those modules.
> 
> If you follow the installation instructions to the letter you do not end
> up in that situation.  If you do not follow the installation instructions
> to the letter then you do so because you think you know how to deal with
> the consequences and are prepared to deal with them.  Yes, there is a
> third possibility: that you are so completely clueless that you do not
> know how clueless you are and therefore think you can ignore the
> instructions AND demand help when it all goes wrong.  I have little
> sympathy for those who wilfully follow the path of stupidity. 
> 
> [...]
> > The eval { } _is_ a performance hit, but it may be worth it. If the
> > performance hit is thought too severe, the checks could be enabled by an
> > option ....
> 
> Since the installation process munges certain things in the perl plugins,
> I'd prefer an install-time check.  If everything looks good, install
> the plugin; if there are detectable problems then install a dummy that
> says "this plugin was not created at installation time because of blah." 
> 
> That would be especially good for the C plugins, which just don't get
> built at all if dependencies are missing.  This way you'd get to see
> that check_blah exists but if you try to run it then it explains that
> there were dependency problems.  As it is, you just get missing plugins
> and nothing to tell you that if only you had the right dependencies you'd
> have had the pluging you wanted.  Since a common way of seeing what
> plugins are available is to look in libexec, plugins that don't get
> built because of missing dependencies often create a misleading impression.
> It would be better to have a check_snmp that returns "This plugin is
> unavailable because of missing dependencies" than no check_snmp at all. 
> 
> The down-side with install-time checks for perl plugins is they won't catch
> run-time problems.  But if you follow the installation instructions to the
> letter, and don't try to do clever things you don't know enough about to
> do successfully, then an install-time check will catch the problems. 
> 
> I am all for idiot-proofing, but not when it causes performance issues
> and the people with a need to use it are theoretically not idiots.  Nagios
> is not for the average computer user.  It's for people with a need to
> monitor network services and requires root privileges on a *nix box to
> install and run.  I do not believe it unreasonable for the software
> to assume that the people installing it do actually understand network
> services and know enough about *nix that they deserve the root password.
> These days it may be unrealistic to assume that, but I still think it is
> not unreasonable. 
> 
> Now if you were to propose a test at build time that checks the person
> doing the installation understands the underlying concepts of *nix
> shell, Apache web server, etc., and refuses to build unless the score is
> high enough, I'd whole-heartedly agree.  But others, including Ethan,
> would disagree so I won't suggest that.  I'll just think it...  And dream
> of LARTs...