targetting for multiple perl versions

bagyi has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: targetting for multiple perl versions by GotToBTru (Prior) on Sep 30, 2015 at 02:13 UTC
This is the sort of thing you put into the tests you run for each install. Another option is to restrict yourself to modules that were installed for version 5.8 .. probably not a very satisfactory option. This is a topic that I know has been discussed here before. Super Search may find some useful suggestions for you. Dum Spiro Spero	[reply]
Re: targetting for multiple perl versions by perlron (Pilgrim) on Sep 30, 2015 at 05:05 UTC
Hi I hope you find this relevant. This is the strategy i use for my perl project deployments On an individual machine instance, you can always use perlbrew to manage multiple installations of perl. The neat feature of perlbrew i like is when you switch between perl's it takes care of updating the @INC path to point to the library paths corresponding to the perl version you have switched to. Again to install modules, of course there's the cpanm utility which takes care of installing to the correct library paths.Additionally while installing any module on a system, one can always check the dependencies prior using `cpamn --showdeps Module_Name` I always use `perldoc -l Module_Name` (eg: CGI, CGI::Application) to check if the said module is installed under the correct version of perl in my system.I'm sure there are better ways to do this though, depending on the need of the moment. Now coming to different machines, assuming you are talking of web development projects, one strategy is to use a framework that works with even earlier versions of Perl(like Mojolicious which works all the way down to 5.10, which i am using, there would be many more), that way even though you're on 5.10, you still have to install those additional modules, but at least your main code base is not going to change. I have also recently been introduced to stratopan for managing large private(in my case) installations of perl code,better library management, and simplifying the deployment process, but that's something i'm not experienced in, just pointing you towards it. The Great Programmer is one who inspires others to code, not just one who writes great code	[reply] [d/l] [select]
Re: targetting for multiple perl versions by james28909 (Deacon) on Sep 30, 2015 at 02:48 UTC
If your using windows, you could pack the desired script and modules into an exe with one of the many tools available, I use perlapp (comes with AS Perl Devkit but its kind of pricey). Then you can distribute it freely.	[reply]
Re^2: targetting for multiple perl versions by Anonymous Monk on Sep 30, 2015 at 03:02 UTC
Then you can distribute it freely. :) Nope. When there are conditions its not "free".	[reply]
Re^2: targetting for multiple perl versions by dasgar (Priest) on Sep 30, 2015 at 19:01 UTC
I agree with the general concept of packaging the Perl script into a stand alone executable. That's the approach that I would take. It gives you the benefit of not having to worry about the Perl environment on the "production" systems. The method that I personally would go with is to use the pp utility from PAR::Packer. It will basically package your script, needed modules (and libraries and files) along with the Perl interpreter into a stand alone executable that can be run on other systems that are running the same (or compatible) OS used to run the pp utility.	[reply]
Re: targetting for multiple perl versions by Anonymous Monk on Sep 30, 2015 at 01:27 UTC
install the needed modules	[reply]
Re: targetting for multiple perl versions by locked_user sundialsvc4 (Abbot) on Sep 30, 2015 at 05:30 UTC
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.
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]