skarface
skarface

Reputation: 910

Loading a specific version of a perl module

I'm looking for a way for a module (or script) to be able to load a specific version of a module (mainly looking at in-house modules, if the solution doesn't work with CPAN modules that's ok).

I'd prefer for this to be largely a packaging exercise (like the way npm/nodejs works). My code defines the versions of the module it wants, then when the use happens the correct module version is loaded.

If it can't be done at the packaging level, is there a sane way to handle this in code? I really don't want to litter the module (or the module's USE-er) with

if($api_ver eq '1.1'){    }
elsif($ap_ver eq '2.0') {  }

More generally, I'm trying to come up with a sane way to track versioned APIs at the module level.

I looked at only per this post How can I 'use' specific version of a perl CPAN module? but the unit test report is fairly bad, and the module hasn't been touched in 6 years as far as I can tell (still on my list to play with though)

Edit: Essentially I'm asking if different modules in my application can use different versions of the same module. Something like:

Module A
   load version 1.0.1 of Module Foo

Module B
   load version 2.1.0 of Module Foo

Module A & B are part of a larger piece of software and Module Foo is also locally written (as I said, I'm less concerned about CPAN versions) I'd like to be able to make API breaking changes to Module Foo without having to uplift every module that uses it. Yes, eventually version 1 of module Foo may end up deprecated, and code would have to be uplifted at that time.

Upvotes: 4

Views: 486

Answers (1)

simbabque
simbabque

Reputation: 54323

I have solved this in the past by having a copy of the dependency in all versions, with the version in the namespace. That seems like it's code-duplication, but it's really just making sure you provide a stable API without relying on all the loading.

API::Version1::Dependency
API::Version2::Dependency

If we are talking a web-faced API (maybe REST), you can have your APIs be seperate processes so they don't get conflicts of loading stuff, and call them with something like http://www.example.org/api/1/frobnicate

Upvotes: 2

Related Questions