Now that I have your attention, what I mean is this:

use 5.6.0;

The 'use VERSION' syntax only became available in 5.6 -- older versions of Perl won't even compile it to report a proper error about the perl version. Update: ikegami pointed out that 'use VERSION' is older -- only the dotted-numeric part is 5.6 or later.

$ perl555 -e 'use 5.6.0' syntax error at -e line 1, near "use 5.6" Execution of -e aborted due to compilation errors.

Moreover, it uses the dotted-numeric form that older Perl's don't understand.

$ perl555 -e 'require 5.6.0' Can't locate 5.60 in @INC (@INC contains ...[snip]...) at -e line 1.

Instead, use one of these:

require 5.006; # run-time BEGIN { require 5.006; } # compile-time

These do what you want.

$ perl555 -e 'require 5.006' Perl 5.006 required--this is only version 5.00505, stopped at -e line +1.

If you're writing modules for others to use (e.g. CPAN), and need a minimum perl version, put a 'require 5.006' (or whatever version you need) at the top of your Makefile.PL or Build.PL. This will die with a useful error message before the Makefile or Build file is created. Moreover, CPAN Testers clients like CPANPLUS and CPAN::Reporter will recognize the error message and file an 'NA' report instead of a 'FAIL' report.

I wonder if there is a Perl::Critic policy about this. If not, there should be.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Replies are listed 'Best First'.
Re: Don't use 5.6.N (why)
by tye (Sage) on Oct 17, 2007 at 16:59 UTC
    Instead, use one of these:
    require 5.006; # run-time BEGIN { require 5.006; } # compile-ti­me

    I agree except for your comments. Instead you should only use:

    require 5.006; # reason 5.006 is _required_

    (with or without the BEGIN block).

    There was (I hope it isn't still the case) a helper tool for creating modules that just stuffed in "require $];" into your module. This was a horrid idea.

    "require 5.006;" does not mean "I haven't bothered to test with versions prior to Perl 5.006 and so can't guarantee that it works there". It means "I have tested on perls prior to 5.006 and can say for sure that this module fails on those versions" (well, it means at least the last half of that).

    So, either leave off the "require 5.006" or add documentation about what you found (or just know) that doesn't work on such versions. Leaving it off isn't such a bad thing. The errors that result are usually pretty clear and tell you more than just "your Perl is too old", they highlight which new feature your old version of Perl doesn't support.

    But, most importantly, don't add "require 5.006" (or whatever version of Perl) unless you actually know that such a version is really required.

    - tye        

      I would disagree with this. I feel that saying "use 5.006;" when you haven't tested with older Perls means "I am only willing to support 5.006 or higher". I had a big internal debate about this with DBM::Deep and decided that I simply didn't have the time to worry about 5.005_03 and the like. So, I put it in and that freed me up to use features that are 5.006+ with impunity (such as 3-arg open, warnings, our, and the like). This was a deliberate choice that was based on non-code-related factors.

      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

        No, "use 5.006;" doesn't say much of anything. Do you have some reason you only want to document your reasons in this obscure node that nobody will find? You've said you already have a code template, so just add a comment to your template.

        Update: I don't see how you are disagreeing with me. You do know that your module doesn't work with 5.006 and you even know why it doesn't (as well as why you chose that route). Unless you are disagreeing that such information should be given to your module's users.

        - tye        

Re: Don't use 5.6.N
by ikegami (Patriarch) on Oct 17, 2007 at 16:31 UTC

    The 'use VERSION' syntax only became available in 5.6

    I don't know when it was introduced, but it was before 5.6. For example, it's present in 5.4.5.
    (Upd: It was introduced in 5.4.0. )

    it uses the dotted-numeric form that older Perl's don't understand

    Isn't the syntax deprecated or invalid in future versions too?

    older versions of Perl won't even compile it to report a proper error about the perl version.

    It seems to me that syntax error at -e line 1, near "use 5.6" has a pretty obvious meaning. That's a poor reason.

      I don't know when it was introduced, but it was before 5.6

      You're right. I was fooled by a funny, little quirk:

      $ perl555 -e 'use 5.006' syntax error at -e line 1, at EOF Execution of -e aborted due to compilation errors. $ perl555 -e 'use 5.006;' Perl 5.006 required--this is only version 5.00505, stopped at -e line +1. BEGIN failed--compilation aborted at -e line 1.

      Apparently the semicolon is significant.

      So, the broader point still holds not to use dotted-numerics, even with a semicolon:

      $ perl555 -e 'use 5.6.0;' syntax error at -e line 1, near "use 5.6" Execution of -e aborted due to compilation errors.
      Isn't the syntax deprecated or invalid in future versions too?

      I think you're referring to "v-strings" -- v5.6.0 -- whereas this is some magic in parsing use with ordinary 5.6.0 as some sort of bareword. E.g. (and without the semicolon)

      $ perl562 -e 'use v5.8.0' Perl v5.8.0 required--this is only v5.6.2, stopped at -e line 1. BEGIN failed--compilation aborted at -e line 1. $ perl562 -e 'use 5.8.0' Perl v5.8.0 required--this is only v5.6.2, stopped at -e line 1. BEGIN failed--compilation aborted at -e line 1.

      I don't know if the latter is going away or not.

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

        No, it isn't use causing different parsing. 5.8.0 is interpretted as v5.8.0 in versions of Perl that support v-strings. The 'v' is only required if a single dot is used. v5.8 is different from 5.8 (but 5.8.0 is just v5.8.0).

        So the dropping of v-string support should drop the interpretation of 5.8.0 as a v-string whether in a use line or not.

        - tye        

Re: Don't use 5.6.N
by dragonchild (Archbishop) on Oct 17, 2007 at 17:00 UTC
    This is especially important if your code has "use warnings;" in it. That's a 5.006ism and gives a poor error message "Cannot find warnings.pm in ..." when the problem is really "You didn't protect against 5.006isms, dumbass!"

    For reference, my personal coding template is:

    use 5.006; use strict; use warnings FATAL => 'all'; our $VERSION = '0.01'; __END__

    Oh, yeah. our is a 5.006ism, too.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

      "Can't find warnings.pm..." is a better error message than "Perl 5.006 required", IMHO (much more specific). And I can trivially arrange for code that does "use warnings;" to actually work quite fine on an installation of Perl 5.005, so leaving off "use 5.006" would make the code better in two ways.

      Though some people seem to be offended in some way that some people have reasons for using older versions of Perl and your "dumbass" comment indicates that you are likely one of those.

      - tye        

        The dumbass comment was for the person who threw in "use warnings;" without protecting for it. That's aimed at all those CPAN devs who have "use warnings;" in their tests, but not in their code. Running on older Perls is something I fully respect and understand why it happens - both PDF::Template and Excel::Template run perfectly fine on 5.005_03 and I think they'll run on 5.004 (though that's untested). I also know what I went through to get there.

        As for it being a poor error message - that's from experience. I've gotten a lot of "Why is this breaking on machineX when it works on machineY?" as a consultant. A simple "use 5.006;" would've fixed everything. I view it as documenting assumptions through assertions.


        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: Don't use 5.6.N
by ambrus (Abbot) on Oct 18, 2007 at 07:28 UTC

    The problem is, it's not easy to find out for every module yours depends on what minimal version is needed. You may have to download lots of versions of the depended module for that. Similarly, I don't want to have all perl versions installed on my machine just so I can put accurate version declarations to a module.

      Which tells me that the best thing would be to not try to guess at what version of Perl to draw the line at (or to at least guess low). Only draw a line if you at least know that nothing before that line works. For example, if you know that your module doesn't work before 5.005 (not a hard thing to know, since there are so many features that don't work before then, for example, for my ...), then feel free to say "BEGIN { require 5.005 } # No 'for my'" even though the module may not work in even 5.006.

      Also feel free to not draw any line, IMHO. If Perl had a feature for declaring "I have tested this module as far back as version 5.006", then I'd encourage people to use it. I really need to write perlage.pod...

      - tye        

      My general feeling is that it's sufficient to put a use/require version statement for features you use in that file. It doesn't need to be a statement about every dependency. But if, for example, you use a 3-argument open, then at least flag that with a "use 5.006;" statement at the top of the file.

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.