How to handle modules across different versions

[ksublondie]

I have a couple windows servers running scheduled tasks in perl. Once upon a time, they were all in perl v 5.6. Over the years, we've been slowly trying to upgrade the old scripts to and creating the new scripts in the latest and greatest version at the time. So now we're running multiple versions.

Of course, all the common functionality (email sending, network variables, etc) are kept in common modules. Currently, we have a different common.pm for each perl version. Is there a good way to simply have one common.pm for all versions? Or is it inevitable with running different versions?

[haukex]

Hi ksublondie,

It's possible to have a single common.pm and then inside it test for different versions of Perl, e.g. with $^V or $]. If you need to load different modules in different versions of Perl it can get a little more tricky, but see this thread for some potential solutions: The "right" way to make your script run with old versions of perl

What are the actual differences you've got in common.pm across your different versions?

Regards,
-- Hauke D

[ksublondie]

Right now, there aren't any differences because we've just been lucky enough to not experience any changes in the versions we've implemented in the current common.pm files. However, if I were to go back and implement them for the older versions, there would definitely be differences in the modules used and even the implementation of the same modules.

Example: I use Date::Manip for almost all of my date handling, but the module for perl < 5.10 is significantly different than perl >= 5.10.

Loading completely different modules in one version over another is definitely a scenario I will run across as well.

I'll check out the post you provided. Thanks.

[haukex]

Hi ksublondie,

Is there something preventing you from upgrading the modules to the latest version (or, at least, some common version that compiles everywhere) on all machines?

Anyway, if you do end up having to use different modules/versions, one of the solutions in the thread I linked to earlier should be applicable to your situation.

Regards,
-- Hauke D

[dasgar]

Out of curiosity, do you need to keep your scripts as Perl scripts? If not, here's another approach that you can consider. Use something like pp from PAR::Packer to bundle your Perl script into a stand-along executable.

One advantage of that approach is that you don't have to manage Perl environments (versions of Perl installed, which modules are installed, which versions of modules installed, etc.) on multiple systems. Instead, you just manage your development Perl environment and distribute stand-alone executable files. Of course, one drawback is end users will not be able to modify the code as easily (which could be a good thing in certain situations).

If you still need/want to keep your scripts as Perl scripts, there's two other approaches that you can consider. You can use App::FatPacker to "pack your dependencies onto your script file", but I don't think that it will work for XS based modules.

If all of the systems have access to a file server, you can put a Perl installation (such as portable Strawberry Perl) on the file server. The other systems then can map a drive to the file server and use that Perl installation.

Just tossing out some ideas about alternative approaches.