[BBLISA] OS libraries vs. pip/gem/cpan/etc.?
Tom Metro
tmetro+bblisa at gmail.com
Fri Jun 13 17:26:47 EDT 2014
John Miller wrote:
> In the past, I've always defaulted to using whatever programming
> libraries that came packaged with my OS -- Debian, Ubuntu, Red Hat,
> etc
>
> These days, I'm not so sure this is always a great idea: you need
> external packages, but run into version incompatibilites with system
> packages.
I'll answer with respect to Perl. The philosophy I've heard repeated is
that the distribution version of the language is intended to support
system administration automation that the distribution relies on, as
well as other applications packaged for that distribution.
If you are running an in-house developed application or or something
that isn't packaged for your distribution, then you are better off
running them in an environment separate from the distribution.
perlbrew[1] is a popular tool for setting up and maintaining a custom
Perl version for your application. I assume Python, Ruby, etc. have
similar tools.
This does put more maintenance responsibility on you than using the
distribution version, but the language version included in Linux
distributions is usually quite stale, and this is well worth the effort
if the application is important to your business. (For example, just
released RHEL-7.0 has Perl 5.16.3, 2 major releases behind the current
5.20, and considered too old to be supported[3] by the community, except
for "critical security patches".)
As for library dependencies, once you've segregated the language
environment from the distribution, you're better off using the packaging
system supplied by the language. A tool like pinto[2] can help you
create a private CPAN to manage the rollout of version upgrades and
distribute in-house libraries.
1. https://metacpan.org/pod/distribution/App-perlbrew/bin/perlbrew
2. https://metacpan.org/pod/distribution/Pinto/bin/pinto
3. https://metacpan.org/pod/perlpolicy#MAINTENANCE-AND-SUPPORT
On the other hand, if I was creating a small bit of system automation in
Perl and was short by a CPAN module or two that wasn't available from
the distribution, then I'd use the tool for repackaging the CPAN module
as a distribution package, as Ryan describes.
-Tom
--
Tom Metro
The Perl Shop, Newton, MA, USA
"Predictable On-demand Perl Consulting."
http://www.theperlshop.com/
More information about the bblisa
mailing list