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

Hello:

Quick Summary: A new version of module isn't backward compatible. How can I incrementally upgrade pieces of a complex system that use this module?

I love Class::MethodMaker. It is used by almost every module I write (and I mean every). Unforunately the module has gone through a major interface change from v1.12 (which I use now) to v2.0x and I, of course, used lots of features which are not backward compatible. There are no technical reasons why I can't keep using the old 1.12, I just don't like using or having to install older, outdated, unsupported versions of currently available CPAN modules.

I also didn't simply use this module but inherited from it and made some nontrivial changes to how object inheritance, creation, and initialization work. This means I'm going to need to sit down and really understand how the module is working now and do some extensive functional behavior testing on it.

Once this is done, I expect it will take a week+ to get all my current scripts and modules changed over and tested. This is a week I just can't justify spending.

And of course the problem compounds itself in that any new code I write has to use the older version of the module too...so the situation keeps getting worse.

I can't come up with a good solution and need help.

I'd really like to at least be able to write any new code using the latest version of Class::MethodMaker while somehow letting the old code still work. But this would mean keeping two versions of the same module around. It would also mean, quite possibly, needing to have two versions of the same module loaded at the same time.

Is there any way I can do this? Is it possible to have two versions of the same module out there on your @INC and pick which one you use? Is it possible to actually load two different versions of the same module into your program at the same time?

Or am I looking at this problem in the wrong way? Are there any other possible solutions I've overlooked or help you can offer me? I've been struggling with this problem for a while and haven't come up with anything.

Currently I'm being forced to install the older versions of the library and do a

use Class::MethodMaker 1.12;

I know my example specifically mentions Class::MethodMaker but I've been pondering this same issue about some other modules I've written and for Perl in general. Normally Perl lets you do almost anything but it seems like this might be too much even for Perl.

And as an aside, what is going to happen when Perl6 comes out? Can you have both Perl5 and Perl6 installed on your system or will it be an all or nothing deal? All I have been able to discern so far is it is looking like Perl6 wont be compatible with Perl5.

Thanks

Update:

I realize I can install a local version to test / build with and I will be doing this for my initial work but once this is done, then what?

I have 4+ projects each using 30+ modules (many shared, some not) which almost all use this one module. The only choice seems to be update ALL the code at the same time to use the new module or update none of the code. I've been hoping there was something else besides the all or nothing solution.

I suppose this is what a CVS fork is for...but I really don't want to go that route either

Fendaria

Replies are listed 'Best First'.
Re: Two(+) versions of same module?
by ysth (Canon) on Apr 29, 2005 at 21:17 UTC
Re: Two(+) versions of same module?
by suaveant (Parson) on Apr 29, 2005 at 20:37 UTC
    I would suggest putting the new version in a directory somewhere not in the default @INC. Then do a use lib to the new directory in any ported software... Perl goes through @INC in order, and takes the first lib it finds that matches, use lib prepends to the list.. voila!

    once you think everything is ported, move the new one into a proper directory and delete it fromthe test dir.

    You could then take out the use libs, or leave them there for future testing (which could be very useful).

                    - Ant
                    - Some of my best work - (1 2 3)

Re: Two(+) versions of same module?
by jhourcle (Prior) on Apr 29, 2005 at 20:37 UTC

    It's possible. I maintain multiple versions for development purposes. It's fine for stand alone scripts, CGI, FastCGI ... but not mod_perl.

    For the 'alternative' module, you'll want to install it in some location outside of your normal @INC and just use lib '/path/to/library/base';

    You'll also want to take note that the syntax use Module version; will use that version or greater, and will not restrict it to that specific version. If you wish, you can inspect $Class::MethodMaker::VERSION and abort if the wrong version was loaded.

      Ya, I just checked my code and I did stick in a check on $VERSION and croak if it isn't 1.12 in the BEGIN of the module.

      Although I swear I thought Perl had a builtin way to with use to require a certain version of a module. But perhaps I'm thinking of a different language, TCL maybe.

      Fendaria
Re: Two(+) versions of same module?
by tilly (Archbishop) on Apr 30, 2005 at 00:14 UTC
    I thought once that I would have a similar problem, and wrote Versioned modules as a proof of concept to deal with it.

    In the end I didn't have that problem, and so the proof of concept has remained just a proof of concept.

Re: Two(+) versions of same module?
by naChoZ (Curate) on Apr 30, 2005 at 00:53 UTC

    If you're using scripts with Apache, another convenient way to make additions to your @INC path is with an .htaccess file. Just create it in the same directory as the script and add something like:

    setenv PERLLIB "/path/to/lib:/path/to/other/lib"

    --
    "This alcoholism thing, I think it's just clever propaganda produced by people who want you to buy more bottled water." -- pedestrianwolf

Re: Two(+) versions of same module?
by itub (Priest) on Apr 30, 2005 at 12:01 UTC
    Can you have both Perl5 and Perl6 installed on your system?

    I don't see why not. I have four different versions of Perl 5 installed. The only problem is binary compatibility of extension modules.