We run the identical version of Perl with an identical set of CPAN modules on all our many different Unix boxes (multiple versions of: AIX, HP-UX, Solaris, Red Hat Enterprise Linux (RHEL), Digital UNIX, Tru64 UNIX, IRIX, UnixWare, SCO Unix, ...).

I install this perl in the same well-known location on each of our boxes and adjust the PATH so that we use this version of Perl for all our work. We never use, or meddle with, the system /usr/bin/perl. We also ship our Perl distribution with all our products. Using the same (stable) Perl distribution everywhere avoids many annoying portability glitches ("it's easier to port a shell than a shell script").

To achieve this, I put the source tarballs for perl and all the CPAN modules on a shared drive available to all our Unix boxes, then run a script that builds perl from source (Configure, make, make test, make install), followed by building all the CPAN modules from source (perl Makefile.PL, make, make test, make install). The script contains an array of CPAN modules and builds them in the specified order. Because our Perl distribution must run on customer machines, and we don't want to meddle with their /usr/lib or /usr/local/lib, I have to take care to build any CPAN modules that depend on C libraries (e.g. XML-Parser) in such a way that they are wholly contained in our Perl distribution and don't depend on the contents of /usr/lib or /usr/local/lib. Only our build script is currently under version control. It would be easy to put all the tarballs under version control also -- and I probably should -- though I haven't bothered so far, mainly because they are essentially unchanged from the CPAN tarballs.

This scheme has worked reasonably well here because we require stability and repeatability (we typically update our Perl distribution only once every two years or so). One nuisance is when we need to make an emergency fix to a CPAN module. In that rare event, I unpack the CPAN module tarball, make the fix, then repack it into a new tarball with a different name, updating our build script to use the new tarball. Ugly. Since I've only needed to do this once, I haven't investigated a better way to deal with this use case. Ideas welcome. Notice that if you need to make an emergency fix like this, it's in your best interests to send the fix back to the module author as soon as possible, so as to get a proper code review and to avoid the long term burden of maintaining your own custom fork.

Though the above scheme has worked well for me here, it's probably not appropriate in a more volatile Perl environment, and I'm interested to hear how other folks deal with that.

BTW, so as not to meddle with customer /usr/lib or /usr/local/lib (and to avoid the dreaded LD_LIBRARY_PATH, see also Re: Portable Perl?), and to not require root permissions, our install script used to binary-edit our executables, replacing their artificially long build PATH with the customer chosen install directory with our lib sub-directory appended.

Related CPAN Modules

• Pinto by Jeffrey Ryan Thalhammer
• Carton by Tatsuhiko Miyagawa
• CPAN::Mini::Inject by Christian Walde
• MyCPAN::App::DPAN by brian_d_foy
• CPAN::Site by Mark Overmeer

Pinto References

• Announcing: Pinto by jthalhammer (2012)
• Pinto on FLOSS Weekly next Wednesday by jthalhammer (2013)
• FLOSS Weekly Interview on Pinto by jthalhammer (2013)
• Announcing The Crowd-Funding Campaign For Pinto by jthalhammer (2013)
• Pinto Jam Sessions On IRC This Thursday by jthalhammer (2013)
• chef pinto cookbook by melezhik (2013)
• how to build perl projects using pinto and pjam by melezhik (2013)
• Pjam - continues integration for PERL, using pinto. by melezhik (2013)
• Re: Multiple package versions (use only modules cpanfile pinto carton local::lib install_base)) by anonymonk (2015)
• Interview with Jeffrey Thalhammer (perlmaven)

Related Perl Monks Nodes

• Re: Prefer Pure Perl Core Modules by Fletch (2021) - warns if you're doing anything serious with Perl you DO NOT want to use the OS' perl as that way lies much pain
• Re^4: catch die from say (Building your own Perl) by me (2024) - advises PierreForget to forget about the system perl, instead to build his own perl as non-root
• Re: Replicate Perl setup (Building and Installing Perl References) by me (2021)

• Re: Replicate Perl setup by Fletch (2021) - notes that the core CPAN module has a handy autobundle command
• Unix shell versus Perl by me (2008) - Perl scripts preferred to a motley mix of Unix shell and Windows .BAT scripts

• Re: Out-of-the box Perl version - lowest common denominator by me (2021) - notes that non-technical customers lack the skills and desire to build their own perl ... while building our own perl vastly improves and simplifies customer support, e.g. it's easy to set up test environments in our office identical to what the customer is using
• Howto Bundle Perl (2009) - asks for advice on bundling Solaris perl with a software product that depends on it

References Added Later

• Re^4: uparse - Parse Unicode strings (locate/find/xargs) (2023) - discusses Linux mlocate utility
• Network-attached storage (NAS) (wikipedia)

Updated: "Related CPAN Modules" and following sections were added long after the original reply was made.