6

I would like to migrate a perl library (SOAP::Lite) used by my application. To to the migration as smoothly as possible for the end-users, I would like to have the two versions of this library (the old one and the new one) to work in parallel.

The goal is to let the end-users migrate their scripts (if needed) by themselves, whenever they want. So basically, for the old scripts the users would have nothing to change, and the new scripts would be written using the new version.

Does anyone know a way to proceed ?

dounyy
  • 666
  • 12
  • 24
  • As a workaround, you can use [perlbrew](http://perlbrew.pl/) to install a second copy of your system perl version. System perl won't know about perlbrew's libs and perlbrew won't use system perl's libs. *Caveats*: 1) use `perlbrew install-cpanm` to make sure perbrew modules ARE installed under the right path 2) All your scripts should start out as `#!/usr/bin/env perl` instead of `#!usr/bin/perl`. 3) Be careful with `PERL5LIB` env var - may break this scheme. In fact, I wish perlbrew could install the same version twice under different names... – Dallaylaen Oct 09 '15 at 10:22
  • It's not possible to have the same CPAN module twice in the same Perl. I'm looking for a q/a that has that explained. – simbabque Oct 09 '15 at 10:24
  • In fact, you could use local::lib + cpanm, and then make ~/perl5 a symlink changing between perl5-old and perl5-new (I assume a Unix system here). – Dallaylaen Oct 09 '15 at 10:28
  • 1
    I'm a bit confused. Is your application a module that is itself used by other Perl scripts? If not, can you please explain the relationship between your application and the "end-user" scripts? –  Oct 09 '15 at 10:49
  • 1
    For doing this, I've actually been using docker containers. Works quite nicely. – Sobrique Oct 09 '15 at 11:09
  • @dan1111 The application uses Java + Perl. End-users upload their perl scripts in the Java application which will run them (the Java application acts like a task scheduler). Some scripts already exist in the application, and some new scripts are uploaded regularily, hence the compatibility issues. – dounyy Oct 09 '15 at 11:46
  • 1
    In that case, just set a different module path based on whether it is an old or new script. You don't need both at the same time. –  Oct 09 '15 at 11:50

2 Answers2

1

Use only.​​​​​​​​​​​​​​​​​​​​

ThisSuitIsBlackNot
  • 23,492
  • 9
  • 63
  • 110
daxim
  • 39,270
  • 4
  • 65
  • 132
  • Thank you for the link. I don't think is suits here, because it would need the old scripts to me modified too. But I keep think in mind though, I may need this one day. – dounyy Oct 09 '15 at 12:02
1

Since, as you mentioned in the comments, each script is called by a Java application that asks as a scheduler, you don't need both modules "at once". Instead, you simply need one or the other for each run of a script. This can be handled by setting the environment appropriately as an old or new script is called.

You could use solutions such as Perlbrew to manage two or more completely different Perl installations, if you wish. This would be a good approach if you find that you want other differences between the old and new versions.

However, if you simply want to swap out versions of this one module, all you need to do is have both installed somewhere, and alter the module path when you call the script. There are various ways to do this, but you could just use a command-line switch:

perl -Idirectory script.pl

This will add directory to @INC, the set of locations where modules are searched for. Point to the old or new module as appropriate (if you do it this way, make sure that neither version of the module is in the standard module path, otherwise there will be ambiguity as to which version you are using).