Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Artificial perl version dependencies

by rinceWind (Monsignor)
on Dec 21, 2006 at 16:04 UTC ( [id://591122]=perlmeditation: print w/replies, xml ) Need Help??

I know that some of the module creation tools include a requirement for the particular perl version. For example, the boilerplate from h2xs includes by default, a dependency on the current perl version that it is being run on. In many cases, this is not applicable.

In my case, I'm stuck with a 5.6.1 perl at work, but keep finding modules that refuse to load. Sometimes this is genuine with use of 5.8 syntax or semantics. However, there are other times when hacking the module to comment out the dependency allows the module to pass all tests and install.

An example that has occurred today is theDamian's IO::Prompt. I've commented out the use 5.008 and it passes tests.

I know 5.6.1 is quite old now, but it's a pain having modules with artificial dependencies to 5.008, when there's no reason.

--

Oh Lord, won’t you burn me a Knoppix CD ?
My friends all rate Windows, I must disagree.
Your powers of persuasion will set them all free,
So oh Lord, won’t you burn me a Knoppix CD ?
(Missquoting Janis Joplin)

Replies are listed 'Best First'.
Re: Artificial perl version dependencies
by merlyn (Sage) on Dec 21, 2006 at 16:19 UTC
    It may not always be necessary, but h2xs is doing the safe thing here. After all, I'm probably not able to test the module on an older Perl.

    So, the right thing for you to do is to file a bug report to say "your version number is unnecessarily high: I've tested with x.xxx and your tests pass".

Re: Artificial perl version dependencies
by gaal (Parson) on Dec 21, 2006 at 17:11 UTC
    What merlyn said, and: suppose the author decided to maintain a module from 5.8.x, and gets a note from you saying it happens to work on 5.6. Unless the author is willing to continue maintaining 5.6.x from now on, inspired by your check, there's no good way of proceeding. When the next version comes out, should the author wait for you to release? Note that "the author should test against older Perl" is no good, because if they were willing to do that, they'd already have done so!

    One subtlety here is bundled core modules. The corelist for 5.8.x is both larger and has newer version numbers than the one for 5.6.x: if you test a module on an older Perl, you should test against a vanilla install, because otherwise you might not notice breakages. If a maintainer has several distros, and some in fact do rely on non-bundled prereqs, testing on multiple versions becomes tedious!

    (Here's an idea for a project though: a chrooted environment that's easy to set up every time from scratch for testing distro releases.)

      Here's an idea for a project though: a chrooted environment that's easy to set up every time from scratch for testing distro releases.
      It's early days yet, but adamk is determined to solve this "Pain In The Ass" of a problem with his Perl Image Testing Architecture (PITA) project, where PITA::Driver::Chroot is currently marked as "speculative". (See also PITA CPAN module).

Re: Artificial perl version dependencies (backward)
by tye (Sage) on Dec 22, 2006 at 17:51 UTC

    I have to disagree with the support for arbitrarilly including things like "use 5.008" into modules. It is not "the safe thing to do". If you don't know what version of Perl is required for your module to work, then the correct thing to do is to declare that you don't know by not specifying a minimum Perl version! I don't see much good in transforming "I don't know what Perl version this works in" into "I know that this doesn't work in Perl versions prior to 5.8".

    I think a lot of people are misinterpretting "use 5.008" as "I guarantee that this works in Perl 5.008 and later". That isn't what the construct means. The only guarantee with "use 5.008" is that it dies when the Perl version is less than 5.008. So "use 5.008" means "I know that this doesn't work in versions prior to 5.008 so don't even bother to try using it there."

    So please stop this annoying practice. And, if you do include "use 5.008" or such in your module code, then please have the courtesy to include comments noting which feature(s) you have used that make it so your module can't work in prior versions of Perl.

    Update: And to prove this point, let us consider the real world and what happens when "use 5.008" is included or not in a module.

    Say I write a module and don't go to any effort to figure out nor document what Perl versions it works with (and thus don't "use 5.008" nor declare a requirement for any other version of Perl) and then upload this module to CPAN. The CPANTS (the testers) will automatically download my module and try it on a bunch of versions of Perl. Someone wanting to use my module can look at the CPANTS reports in order to figure out which versions of Perl my module works with. In particular, they can likely see if my module works with their version of Perl without even having to download my module (so long as someone runs CPANTS on that version of Perl).

    If, instead, I had included a "use 5.008" in my module for no good reason (because someone mistakenly thinks this is "the safe thing to do"), then all of the CPANTS reports for versions prior to 5.008 will fail with "Perl v5.8.0 required", telling everyone nothing useful.

    In the better scenario, the potential user of my module gets useful information. They either get told that my module works on their (old) version of Perl and also get a module that just works for them. Or, they get told that it doesn't work and can drill down and see what error message(s) go along with that failure and can decide whether that looks like something that is easy enough to fix and they want to try to make the module work on older versions of Perl.

    And I, as the module author, get useful information as well. When I check how my module is being received, I should note that it is failing some CPANTS tests and I can drill down into those and see why it is failing and maybe decide to make fairly trivial changes to my module that might make it work for more people.

    At my work, we have Perl 5.6.0 installed everywhere. The benefit of having Perl everywhere is clear and so it was worth the effort to get Perl into our standard tools pack so that it got installed everywhere. The effort involved was not that great. So we have a clear benefit for fairly low effort.

    Why haven't we upgraded Perl? Because the effort to replace every copy of Perl 5.6.0 with 5.8 is much more than the effort originally needed to get Perl 5.6.0 everywhere. And what benefit is there to 5.8 over 5.6.0 ? Almost none. We actually upgraded to 5.6.0 because we saw enough benefit in that case. Perls prior to 5.6.0 had problems that made upgrading more important. 5.6.0 works great for us.

    It would probably be a good idea to put a fairly new release of Perl into our standard tools pack so that eventually a newer version of Perl will end up everywhere. However, there is risk associated with this so it isn't something we will do lightly. There is risk that upgrading Perl will break something that works on the old Perl. And, it is a pain to get the new Perl being pushed to all of our systems while making sure that the places where people write new Perl code only use the old version of Perl. If the new Perl got onto some developer's platform while Perl was only upgraded on some of the production systems, then we'd surely get a script written that appears to work fine and works fine on some production systems and then causes a bunch of headaches when it gets deployed to a system that hasn't had the new tools pack installed.

    So it is a no-brainer to not update Perl yet. Too much effort and too much risk with dubious gain.

    - tye        

      I agree with most of what you say, but I think you are overestimating the "version diversity" of CPANTS. For example, for one of my modules that's been there for a while and has 34 test results, only one has a version < 5.8.0, and this was a lucky exception. ;-) Most of the test results are for 5.8.5 to 5.8.8. There is a bias towards bleeding edge versions among CPAN testers (I even have results from versions > 5.9.0).

        Yes, this crossed my mind but didn't make it into my text.

        So long as the standard tools for creating modules are inserting "use 5.008" or such into every new module they help create, there is little point in CPANTS testers using older versions of Perl. I wouldn't be surprised if some CPANTS testers have abandoned using old versions because so many modules fail.

        But I think a movement to remove these useless and annoying cases of "use 5.008" (as opposed to the few cases that are there for real and documented reasons) could motivate a CPANTS revival for older versions of Perl. It has certainly sparked my interest in setting up CPANTS for 5.6.0 and 5.6.1. I'm sure there will also be challenges in getting CPANTS running in such environments.

        I'm also collecting the few, simple, fairly easy techniques that I use (or avoid) in order to keep my modules compatible with older versions of Perl. Perhaps even a perlage.pod...

        - tye        

Re: Artificial perl version dependencies
by ambrus (Abbot) on Dec 22, 2006 at 10:30 UTC

    I think you can't reasonably expect a module author to figure out the minimal required version number of perl and all the other modules the module depends on. That would be too tedious. I can understand if the module author errs on the safe side and specifies version numbers he or she is sure will work. That way, people who want to work only with stable software will get no unexpected errors.

    You can of course still try to use a module if you don't have all dependencies satisfied. If you are sure the module works that way and doesn't depend on anything newer, the best thing you could do is write to the module maintainer, who will change the dependencies.

Re: Artificial perl version dependencies
by shmem (Chancellor) on Dec 22, 2006 at 09:26 UTC
    If you're stuck with 5.6.1, my bet is that you're also pretty much stuck on some legacy OS variant for which support is discontinued. Since there are no updates / bugfixes /service packs available, you must do anything by hand anyways.

    So, why not patch e.g. CPAN.pm to do a s/^(?=use +5\.008)/# / on every module before even trying to build it? If something bombs off, you know where to look.

    If legacy systems / perl versions were supported, they wouldn't be legacy.

    --shmem

    _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                  /\_¯/(q    /
    ----------------------------  \__(m.====·.(_("always off the crowd"))."·
    ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
Re: Artificial perl version dependencies
by petdance (Parson) on Dec 27, 2006 at 07:06 UTC
    This message irks me in a couple of ways.

    First, to claim that 5.8 is an "artificial" dependency based on your external view of it is silly. You don't know why that 5.8 is there, unless there's something you didn't post.

    Second, you say that "I've commented out the use 5.008 and it passes tests", as if that is proof that 5.008 is not necessary. It might be, it might not be.

    Why don't you email Damian and ask him? Explain your situation and ask his opinion. Explain your observations and ask for clarification.

    xoxo,
    Andy

Re: Artificial perl version dependencies
by EvanK (Chaplain) on Dec 22, 2006 at 15:12 UTC
    I share the OP's pain. At work, until recently I was stuck on a Redhat8 system with perl 5.5.3...still on the same old system, but managed to convince the powers that be to let me install a 5.8 build alongside it

    nonetheless, maintaining code is hard enough without maintaining it on 3 or 4 different perl builds

    __________
    The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.
    - Terry Pratchett

Re: Artificial perl version dependencies
by chromatic (Archbishop) on Dec 21, 2006 at 19:12 UTC
    ... it's a pain having modules with artificial dependencies to 5.008, when there's no reason.

    Is not wanting to support five year old versions of Perl not sufficient reason? 5.6.1 doesn't even build on modern systems. How do you expect an author to support it?

      Huh?
      $ uname -a Linux lt-gm 2.6.16-8-smp #1 SMP Tue Mar 28 11:00:06 UTC 2006 i686 i686 + i386 GNU/Linux $ /home/shmem/comp/perl5.6.1/bin/perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuratio +n: Platform: osname=linux, osvers=2.6.16-8-smp, archname=i686-linux uname='linux lt-gm 2.6.16-8-smp #1 smp tue mar 28 11:00:06 utc 200 +6 i686 i686 i386 gnulinux ' ...

      It does build. As does perl4.0.1.8 (patch level 36). Another question is whether it's sensible to use it.

      What is a 'modern system' for you? I'm running OpenBSD 4, SuSE 10.1.

      --shmem

      _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                    /\_¯/(q    /
      ----------------------------  \__(m.====·.(_("always off the crowd"))."·
      ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

        I haven't tried; the reasoning I remember for Perl 5.6.2 was because it wouldn't build with a modern GCC, for example.

        I believe chromatic is speaking about Fedora/Redhat. IIRC They made some non-standard (at the time) changes to gcc, which caused many programs not to compile.

        grep
        1)Gain XP 2)??? 3)Profit

      Rereading my original post, I guess it does appear whiny. I'm not stuck forever in this job with the perl 5.6.1, as I shall be moving on from the client site at the beginning of March. I'm using 5.8.8 for my home environments.

      In terms of a base line perl version when developing CPAN modules, I have been choosing 5.6.1, as it includes our and lexical filehandles. In my CPAN modules, I've not been using any constructs that require 5.8.

      I'm glad this thread has provoked discussion on the subject of support for old perl versions. Going forward, I think it would be useful for some guidelines for module authors, encouraging them to think about the following questions:

      • What is the minimum perl version you are willing to support?

      • What is the minimum perl version the module has been tested against?

      • What is the perl version before which the module will definitely break?

      With perl 5.10, or indeed perl 6, this topic will be bound to resurface.

      --

      Oh Lord, won’t you burn me a Knoppix CD ?
      My friends all rate Windows, I must disagree.
      Your powers of persuasion will set them all free,
      So oh Lord, won’t you burn me a Knoppix CD ?
      (Missquoting Janis Joplin)

      Is not wanting to support five year old versions of Perl not sufficient reason?

      No.

      (Damn double-negatives ... they always make one stop and think ... :-)

      Cheers,
      Rob
        Tough. Go fork it and maintain it yourself.

        xoxo,
        Andy

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://591122]
Approved by Corion
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others rifling through the Monastery: (7)
As of 2024-03-28 11:20 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found