[Nagiosplug-devel] Integrating Nagios::Plugin into the distribution

[Gavin Carr]

On Fri, Apr 27, 2007 at 01:05:51PM +0100, Ton Voon wrote:
> On 27 Apr 2007, at 11:06, Gavin Carr wrote:
> > b. Do we install Nagios::Plugin to the standard perl library
> >    directories, or do we allow and support installation elsewhere
> >    (e.g. to a local nagios tree)?
> 
> We always install into a nagios tree, say, /usr/local/nagios/lib. We  
> don't support installation into system dirs - use CPAN or do it  
> manually if you want that (okay, that's probably a bit harsh - I  
> guess we could provide a configure flag, but it is not a priority).

Why? What's the advantage of not using the standard perl library 
locations?

N::P and every other module you're installing _are_ standard CPAN 
modules, that out-of-the-box (perl Makefile.PL; make; make install) 
install into the perl lib directories. You're having to jump through 
extra hoops for them to _not_ install there, and then jump through 
more hoops for your plugins to work because they aren't there. I 
don't understand the rational/benefit of all that extra hoopage?

I guess I'm seeing the benefit of bundling being not having to jump
through setting up the CPAN configuration stuff on every box you 
want to use N::P on. It sounds like you're seeing the isolation itself
as being a benefit?

> If a user decides to install from CPAN or OS packages, obviously that  
> would be placed in system directories.

> > It sounds like there's a reasonable consensus on (a) that we do
> > want to bundle N::P. This needs something like your nanocpan, and
> > presumably a reasonably test suite for the perl plugins to ensure
> > that the set of modules we're snapshotting do play nicely together.
> 
> I'm thinking that the nanocpan is going to be based on Krang's  
> techniques. I'd like to make nanocpan generalised so that it can be  
> used outside of Nagios Plugins and can be given back to the perl  
> community.
> 
> I don't think any additional test suites are required, right? As long  
> as N::P's test suite pass, then the dependent stuff has done its job.

I guess that's right. I was thinking we should be testing the end-plugins
themselves too, but if the N::P tests are comprehensive enough, we should
be covering that off.

> The beauty about the snapshoting is that we know for this specific  
> combination of perl modules, N::P will work (because we'd also be  
> running tinderbox builds daily to prove it too).
> 
> > I'm not sure a good case has been made for (b) yet - to play devil's
> > advocate, why don't we just mandate that N::P and friends, if
> > installed directly, always get installed to the standard perl lib
> > tree? This makes the whole search problem go away. Is there a good
> > case for doing anything else?
> 
> I haven't found the search path to be a problem. I guess lower  
> versions of perl may pose a problem - I don't have a handle on this  
> yet. There may need to be some extra work done there to support those  
> lower levels.

It's just a problem in the sense that the plugins won't work without
some explicit lib path tweaking. I dislike your FindBin/use lib code
on the grounds that it's only required to support a particular
deployment decision - you're polluting the plugins with installation
policy. (It would be much cleaner, for instance, to see if we can just
get PERL5LIB set in the environment if we do go this way).

> Installing into system directories affects other people's code. I'd  
> rather not be responsible :)

You're not - it was whoever pressed that install key. ;-)

Okay, so you're seeing the whole separate-install thing as a feature,
isolating you from screwing up (or being screwed up) someone else's
libraries?

I guess I'm seeing that risk as relatively small, especially given the
modest set of dependencies we have. I'm much more suspicious of the 
duplication problem. If you end up having multiple versions of the same
modules in different locations, you're going to be prone to all kinds
of weird problems if you're not careful. Simple example: imagine an 
N::P from CPAN and a different N::P installed in /usr/local/nagios, and 
home-grown or third-party perl plugins behaving in very confusing 
ways dependent on which way the lib path is set up ...


Cheers,
Gavin