Re: targetting for multiple perl versions

From a broader perspective, the real issue is that your development environment is radically different from production ... which, by the way, is also quite old. This is really what needs to be addressed, and there are three ways to do it: bring production forward, bring your development environment backward, or meet in the middle.

CPAN libraries are version-specific, and they resolve these version differences when they are installed. Sometimes, newer versions of packages (such as the versions now on your development box) might not run, at all, with older Perls. Certainly, they might contain features that your production system’s versions (of the same library) do not support. (And then there are the bugs ...) Nevermind that you might also write your program using a language feature that 5.8 does not have.

In a properly “hardened” production environment, you will not be able to install the packages that you need, at the time that you install your application. (And you will not be able to do either of these things.) You will have to coordinate the sandbox and production deployment issues with I.T.

Replies are listed 'Best First'.
Re^2: targetting for multiple perl versions by Your Mother (Archbishop) on Sep 30, 2015 at 11:59 UTC
CPAN libraries are version-specific This is a gross overstatement. Few are version specific unless we're talking about <= 5.6 and that would be ludicrous to discuss in this context in 2015. In a properly “hardened” production environment, you will not be able to install the packages that you need, Also overstated. It depends entirely upon your build system.	[reply]
Re^3: targetting for multiple perl versions by locked_user sundialsvc4 (Abbot) on Sep 30, 2015 at 12:38 UTC
Lessee ... the earliest “production Perl” that I have seen in the field is 5.4. (Similar experiences with other languages, which have changed far more from point-release to point-release, so with Perl we’re lucky, I guess.) Nevertheless, any large difference of language environments (or library versions, etc.) between Dev and Prod is a big issue that needs to be resolved at its source ... lest you “break production.” As to the second ¶, there are two kinds of “shops”: professionals, and (by the seat of our ...) “pantsers.” Hopefully, you work for the former. In which case, “prod doesn’t change much,” and “you can’t change it at all.” It is often better to change the development environment to exactly match production, even though the developers will glare at you.
Re^2: targetting for multiple perl versions by bagyi (Acolyte) on Oct 01, 2015 at 14:45 UTC
Spot on. I guess coordinating with I.T is the way to go. :-\| The other way is probably to offload processing to server and do minimal work on different OSes/platforms.	[reply]
Re^3: targetting for multiple perl versions by dasgar (Priest) on Oct 01, 2015 at 22:30 UTC
From my point of view, sundialsvc4's points are only valid if you're supplying only source code and are expecting the production systems to have the environment needed to properly run the source code. But that's not the only method to get your code to work on another system. Take a graphical web browser (Chrome, Firefox, Safari, etc.) as an example. Those companies are not providing source code and instructions on what kind of compiler (and libraries and tools and other stuff) you need and instructions on how to configure all of that to properly compile and run their code. Instead, they provide a stand alone executable. Going that route, there is no need to be concerned about the state/configuration of the development tools on systems or even if there are any development tools installed. Instead, just run the executable. That's it. Translate that your Perl code, you could package your code into a stand alone executable and the distribute that executable. Then you don't have to worry with questions like "is Perl installed?", "what version of Perl is installed?", "are the modules that I need installed?", "what module versions are installed?", etc. Just run the executable. One method for doing that is to use PAR::Packer as I described in my earlier response. And going this route eliminates virtually all of the issues raised in sundialsvc4's post. I'm not trying to say that anyone is right or wrong. Just tossing out another point of view for you to consider.	[reply]