If you're doing anything "serious" never run with the OS' perl install. That's just asking for trouble because at some point something is going to break that under you. Something will pull in an upgrade without you knowing and then you're going to be stuck trying to backtrack to working. Especially if you're not on your own machine and there's other admins in the mix.

Always compile your own application install of perl and use PATH and #!/usr/bin/env perl shebangs to find the one you want. What exactly that means is up to you and your mentioned options are both OK. I'd tried perlbrew, never really found it to be compelling enough versus installing to a fixed /somewhere/app/perl/X.YY.ZZ tree and using that and the environment. YMMV though and I'm sure you'll get more comments in its favor (maybe some against . . .).

Edit: Maybe to provide more clarification as to why I tend not to use perlbrew: I manage the perl install for a small-ish (tens of developers) group that manages the "glue" code piping everything together for a (fairly) large custom code base. We have production runs daily so stability of the platform and integrity of numerical results is one of our big "needs". We tend not to upgrade perl versions frequently because to do so would open up needing to do fairly extensive testing to make sure we're not (say) picking up unknown/unintentional numeric drift because something in a floating point library changed (which we've seen happen before). So there's not as much call to have a dynamic pick-and-choose from whatever perl version(s) capacity for our environment, and a fixed install every n years works out OK.

As far as modules, I've toyed with building in a custom symlink'd directory (theoretically pointing to a dated directory underneath that could be swapped) into the PERL5LIB baked into the binary and installled things there into the perl install. That's worked OK in general, but then since doing that haven't tried to do a full "upgrade" of the installed module set so there could be issues with that I never exercised. I'm planning on using local::lib to hold our "current" module set for the next full install we do so we'll see how that goes then . . .

Edit: and to answer your question not sure without seeing the entire exact error message but yes that sounds like you've got XS modules compiled for an older perl now not wanting to load into a newer version. Reinstalling things from CPAN will probably clean those up.

G'day silent11,

I have a variety of installations:

Home - Cygwin (on Win10) - Perlbrew

$ perlbrew list
 * perl-5.36.0
   perl-5.34.0
   perl-5.33.5
   perl-5.32.0
   perl-5.30.0

$ perl -v

This is perl 5, version 36, subversion 0 (v5.36.0) built for cygwin-th
+read-multi
[download]

$work - openSUSE - zypper

$ perl -v

This is perl 5, version 26, subversion 1 (v5.26.1) built for x86_64-li
+nux-thread-multi
[download]

$work - Debian - apt

$ perl -v

This is perl 5, version 32, subversion 1 (v5.32.1) built for x86_64-li
+nux-gnu-thread-multi
(with 47 registered patches, see perl -V for more detail)
[download]

For my home setup, I've used Perlbrew for a very long time (>10 years, I expect). I've had my current machine for 3-4 years. Prior to that I had a Mac Pro (for ~9 years) and used Perlbrew on that also. I tend to get each Perl (stable) version when released. I do a full install of all my main modules on each version using cpan.

For $work, I'm somewhat constrained with what's available and requirements to align with what others are using. I do all module installations with the package manager (indicated above).

Personally, my main Perl is a recent build that I complied myself and keep in /opt (sh Configure -de -Dprefix='/opt/perl5.xx'). That way, I can install CPAN modules into it without the worry of messing up the system Perl, and the modules are in the same directory tree as Perl itself, so I generally don't have to worry about version mismatches. Additionally, when I need a specific Perl version, I use perlbrew, which basically has the same effect of a self-contained Perl, except its environment variables can be applied temporarily. Otherwise, I agree with Fletch to stay away from the system Perl and instead use #!/usr/bin/env perl and PATH to point your scripts at whatever Perl you like. If you do want to install modules into the system Perl, use the system's package manager to do that (though that might not provide all CPAN modules or the latest versions) - I do this on older Raspberry Pis because compiling things there is very slow.

I use perlbrew, which basically has the same effect of a self-contained Perl, except its environment variables can be applied temporarily.

You can use a perlbrew-installed perl in exactly the same way you'd use a self-compiled perl. perlbrew just makes it easier to install (by fetching it for you and applying patches needed to compile older versions) and to use (it can adjust your PATH for you). So I don't get why you don't always use perlbrew.

> d) something else..

Being my day by day on windows the only positive fact is that there is no trouble interacting with system Perl. I concord with Fletch: never run with the OS' perl install!

I use Strawberry perl portable editions, always. I have few of them in a dedicated directory:

ls | grep perl5

perl5.12-32bit
perl5.20.64bit
perl5.22.64bit
perl5.24.64bit
perl5.26.64bit
perl5.28-64bit
perl5.28.32bit
perl5.32.64bit
[download]

ls | grep on windows? Yes I use UnxUtils with pleasure since years.

I have a not published yet program (maybe soon..) to choose the Perl incarnation to cast: it is somethign interactive so you can check various perl distros (not all above distros are loaded by my program) for some feature as, for example, Non-Capturing-Regular-Expression-Flag introduced in perl 5.22 should fail in 5.20

general>get perl_distros
perl_distros=[ARRAY with 5 elements]
        perl5.20.64bit
        perl5.22.64bit
        perl5.24.64bit
        perl5.26.64bit
        perl-5.26.64bit-PDL

general>check_perl_distro -e "print  'hello' =~ /(hi|hello)/n"
 | 1
[OK] C:\EX_D\ulisseDUE\perl5.26.64bit\perl\bin\perl.exe
 | Unknown regexp modifier "/n" at -e line 1, at end of line
 | Execution of -e aborted due to compilation errors.
[OK] C:\EX_D\ulisseDUE\perl5.20.64bit\perl\bin\perl.exe
 | 1
[OK] C:\EX_D\ulisseDUE\perl5.22.64bit\perl\bin\perl.exe
 | 1
[OK] C:\EX_D\ulisseDUE\perl5.24.64bit\perl\bin\perl.exe
 | 1
[OK] C:\EX_D\ulisseDUE\perl5.26.64bit\perl\bin\perl.exe
 | 1
[OK] C:\EX_D\ulisseDUE\perl-5.26.64bit-PDL\perl\bin\perl.exe
[download]

L*

Thanks. I use Windows at work, and had a similar set up with multiple versions of standalone Strawberry. Both Windows and Perl on Windows have grown on me other the years. Anyway, I sort of rolled my own simple version of perlbrew using a bat script to modify a symlink (Junctions) pointing to the "active" version of Perl.

like UnxUtils, gnuwin32 has made working on Windows much more enjoyable. I dabbled with the linux subsystem, but it's too inter-connected to windows binaries for me.

Anyway, I sort of rolled my own simple version of perlbrew using a bat script to modify a symlink (Junctions) pointing to the "active" version of Perl.

If that's the case, I'm sure you'll find great value in berrybrew. Its purpose is to allow you to manage multiple versions of Perl, and even has a handy little UI that runs in the system tray to allow you to switch between them, install new versions etc.

bat script to modify a symlink (Junctions)

I've always wondered how those work. Are they easy to work with? Can you post your script?

Thanks...

d) /pro - (for PROcura, where I work) on all my development systems. I have multiple versions of perl installed there ranging from 5.6.1 to 5.37.0

On my laptop I have additional infrastructure where I can mount a USB disk that has all perl versions ever released (including development releases and RC's) in both threaded and unthreaded build readily available on /media/tux.

When exploring a possible bug in Perl itself, I compile the latest blead and test it there.

When I needed to install older versions of Perl, I've both used perlbrew or installed them manually from the sources.

If you know what you're doing, you can choose either way. If you don't know, nothing will protect you from problems.

Like my fellow renegade dsheroh I too shun the conventional wisdom and for mostly the same reasons. There are some caveats, however. I do not run a rolling-release and do not do any O/S upgrades in-place. Bitter experience has taught me never to do that again and it also enforces a review of what is actually needed at each upgrade time*. Also because of $WORK I tend to keep my local environment in sync with production AFAP and using the O/S perl helps with that. The other main caveat is that I am the sysadmin so am the one in control of the system perl.

For a few years at the turn of the millennium we used a non-standard perl because back then the advances in Perl itself were rapid and substantial and there were requirements to use some of the latest features. So we went the self-compiled route and installed it under /usr/local/perl-$VERSION and went from there. Post 5.8 that became a non-issue once more and I've been using various system perls ever since with zero complaints.

* It is currently upgrade time, so this is all clear in my focus at present.

But a big part of the reason why this works for me is that I don't really care what version of Perl I use. I still write Perl 5.10-compliant code and, although I frequently see people talking about the latest new features added to the language like they're the greatest thing since sliced bread, none of them particularly excite me and I don't miss them. If you do care about your Perl version and/or want all the latest and greatest new features, then using perlbrew is the obvious way to go, since the OS provider's preferences may not align with your own. Similarly, if you're mostly working with things that require specific module versions or are only used by a specific user, then local::lib may make more sense than installing things system-wide.

You can do that because you aren't on a rolling release distro. If you are, you can still use system perl as long as all the cpan modules are in the distro catalog, which they usually aren't. That's when you need to switch to perlbrew. For extreme rolling distros like Arch, that isn't even good enough because the system libs change ABI frequently breaking XS modules, but at least perlbrew makes it easy to throw away and re-install a perl version.

You can do that because you aren't on a rolling release distro.

Good point and, yes, that's also a big factor. Not being a rolling release is one of my primary reasons for choosing Debian and, specifically, Debian stable.

I'm apparently the renegade here: I use the system Perl (Debian's) without reservation.

Same for me, except that I use Slackware. Slackware does not depend on Perl, so I can freely break Perl (never managed to do so).

(Not sure about the new Slackware 15.0, it has some drastic changes compared to 14.2, and so I did not upgrade yet.)

See also Re^2: Perlbrew issues. Suggest a way out., Re^3: NOT NEW but confused - set cpan paths from the start, Re^4: use strict; before/after use warnings;.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

I avoid local::lib. Instead, I use perlbrew. And I create nice convenient aliases, such as

latest       -> 5.36.0
5.36         -> 5.36.0
5.34         -> 5.34.1
some_project -> 5.34.1
[download]

Benefits:

My shell usually uses the latest version (perlbrew switch latest).

I can easy test against multiple versions using

cd "${PERLBREW_ROOT:-$HOME/perl5/perlbrew}"/perls
for v in 10 12 14 16 18 20 22 24 26 28 30 32 34 36; do
   echo "5.$v:"
   5.$v/bin/perl -e'...'
end
[download]

I can easy update the version of Perl used by installed scripts without changing their shebang lines.

d

• work servers, $work maintains system packages for perl and modules, including cpan/cpanm/etc
• work desktop, macports installs multiple versions of perl and a separate cpan/cpanm executables for each. I can run a specific version as, say, perl5.34 or I can select which version is just 'perl' using macports's tools.
• home, I use a portable installation using either perlbrew or Strawberry Perl, or I build from source in, say, /opt/perl5.36 or /home/mischief/perl/5.28 or so and install the modules in each version's own directories