Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??
So, without further ado, here are some arguments in favor of installing your own Perl (in no particular order):

I strongly disagree with almost all of them, because they all start from the same point. Why?

short answer

If it ain't broke, don't fix it. You should probably NOT mix your custom libraries with the system libraries, but that is a whole different point. Perl has PERL5LIB, lib, FindBin and more ways to include paths unknown to the system within perl's search path.

long answer

All of the arguments in favour of installing your own perl don't hold if the system's perl isn't suspicious in one or another way. I rarely found a seriously broken perl core installation - well yes, RedHat is doing such a terrible job here sometimes that one might suspect they want to discourage the use of perl all together. But in general, the perl core installation is - just perl core fine-tuned to the capabilities and requirements of the system you are using. Why would you be smarter configuring a suitable perl than those which oversee the whole system?

If the perl core of your system isn't too much outdated for your needs, why not just use it, along with the pre-compiled packages provided by your vendor? Your system probably provides a toolchain to build perl packages, and with minor tweaks, you can install any additional or newer version of needed modules into a custom path, even application-wise, and prepend that location to your @INC. That way you are only responsible for those packages which you absolutely need with newer features or custom bug fixes.

Some reasons why your system's perl might be better than a custom built perl:

  • the systems's perl is always up to date with system libraries
  • your vendor might provide you with new packages containing securtity/bug fixes for problems you are not aware of
  • the vendor's approach is almost always conservative - they are not interested in breaking perl (but see RedHat) as part of the system
  • using a reasonable well built perl including packages built with that perl and it's toolchain saves you work and reduces your technical debt
  • chances are higher that problems within your system's perl are known out there, and that there is a fix - you might get better support and hotfix packages

Of course, if building your essential modules turns out to be a nightmare with your vendor's perl - then that perl build is broken. Roll your own, complain, and if possible, provide upstream patches.

perl5porters, module authors and the perl community at large as well as vendor software maintainers are generally doing an awfully good job at providing a perl out of the box which just works, and deficiencies of older UNIXes like AIX or Solaris, b0rken stuff like RedHat's perl v5.8 or braindead update procedures like on MacOS are no reason to degrade perl's fame of being way better in backward compatibility, write once - run everywhere and robustness than Java, Python or PHP.

Generally advocating always roll your own perl is a disservice to perl users and programmers.

tl;dr

If you know what you are doing, and why - build your own perl. But always disregard the system's perl and build your own MUST NOT become another of those recommended Perl Best Practices.
Summary:

In summary, unless you are writing an OS-level tool specifically for this platform, install a Perl version specifically for your own application's runtime stack.

If the perl shipped with your OS is broken, get another OS. Why should the OS be any less broken than perl on that OS?

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

In reply to Re: RFC: (Do Not) Modify the System Perl by shmem
in thread RFC: (Do Not) Modify the System Perl by MidLifeXis

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (3)
As of 2024-06-17 16:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?
    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.