in reply to Production Environments and "Foreign" Code

I've used a lot of CPAN modules in production code. CPAN is probably the primary reason I use perl for most of my work since it enables me to build quality apps quickly. Not using CPAN is... foolish :-)

The important thing is to have some sort of process. My general rules when using other peoples modules are:

Even if you do all of the above it will still take less time than writing something like DBI or Template from scratch.

I've only very occasionally had problems. Some of the non-upward compatable changes made to Class::DBI being the only ones that ever caused serious hassles - and that was because somebody else ignored the last point above :-/

Hope this helps.

  • Comment on Re: Production Environments and "Foreign" Code

Replies are listed 'Best First'.
Re: Re: Production Environments and "Foreign" Code
by PodMaster (Abbot) on Mar 12, 2003 at 15:04 UTC
    ++adrianh.

    I absolutely refuse to install any module without a test suite (and I hate changelogs which lie -- diff is key).

    Another tip is to not rule out modules with artificial requirements.

    A module may say use Foo 5.5, but that may be only because that's the version they had installed (test anyway).

    Also, you can find lots of useful modules which could work with your version of perl, if they used the vars pragma instead of our $VERSION = 3.1;.


    MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
    I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests.
    ** The Third rule of perl club is a statement of fact: pod is sexy.