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

I have gotten in the habit of using the cool lexically scoped file handles. 

open my $out, ">", $filename or die $!;

[download]

http://testers.cpan.org is just about the coolest thing ever; because, you can see how your modules hold up on platforms you don't actually have.

There are a number of testers still using perl 5.6.1, which doesn't handle my $out filehandles well. It seems to actually fail during the parser pass on a print $out Object->method() line. So I guess I could try print {$out} Object->method(). I don't think the open line is going to work though — but it's been a while since I've used perl 5.6, so who knows.

Questions: What is the most appropriate way to deal with the problem? Should I go back to open IN, $filename? Otherwise, how do I instruct ExtUtils::MakeMaker that the module won't load without perl 5.8? I can get the Makefile.PL to crash with use 5.008001;; but what will CPAN.pm do with that? Is that the correct way?

I'm mostly interested in the correct way to require perl 5.8 in a way that CPAN understands. But all comments are welcome obviously.

UPDATE: open my $c is apparently in the perl56delta. But I still wish to know how you'd handle a syntax that requires a certain later perl version.

-Paul

Replies are listed 'Best First'.
Re: testers.cpan vs perl 5.8
by Herkum (Parson) on May 15, 2007 at 19:07 UTC

    The way I understand it, if the Makefile.PL blows up it will not continue with the install. If you are truly concerned about it why not write a unit test that fails if you a version earlier than 5.8? That might be the easiest way of preventing that from installing.

    If you are writing something that has to be compatible with a lower version I would use syntax that both versions can understand. The 'open my $out' syntax is easier to read but obviously does not pass PBP compliance. I would disable PBP compliance checking for that syntax and use syntax that is portable as long as portability is the issue.

[reply]
      The requirements in the Makefile.PL serve a much different role than the tests.

      I'm interested in informing the CPAN.pm of the higher perl version requirement, similar to PREREQ_PM => { "module::name" => 1.0 } rather than just crashing the thing during install or testing.

      The difference is that, when a module is missing, ExtUtils::MakeMaker announces, "Warning: prerequisite "module::name" 1.0 not found." rather than just crashing. That tells CPAN to go get that thing.

      I remember back in the olden days, a lot of modules would require perl 5.6 and cpan would keep trying to download perl-5.6.tar.gz. That was irritating on dialup. Perhaps they removed the automatic perl version requirements because of that or perhaps "use 5.008001" is the correct way. I do not know.

      -Paul

[reply]
[d/l]
[select]
        The correct way is "use 5.008". (You probably don't want to "use 5.008001", as that will also kill the Makefile.PL on perl 5.8.0.)

        I don't know for a fact that CPAN.pm will handle that correctly, but I would be surprised if it didn't - and if you find that it doesn't handle it correctly then a bug report is in order.

        If you have perl 5.6 and you want to check, try installing Net-SSH2-0.09 (whose Makefile.PL does "use 5.008") using CPAN.pm.

        Of course, if there once was a version of CPAN.pm that didn't do the right thing, then it's quite possible that some people are still using that version ... probably not much you can do about that. (I expect that the cpan testers would be using an uptodate and relatively bug-free version of CPAN.pm.)

        Cheers,
        Rob
[reply]
        I remember back in the olden days, a lot of modules would require perl 5.6 and cpan would keep trying to download perl-5.6.tar.gz. That was irritating on dialup.

        Ah, fond memories. This was a bug in the dependency analysis of CPAN.pm itself. Andreas König fixed up CPAN.pm to avoid doing this. But you still had to upgrade your local CPAN distribution to get the fix.

        • another intruder with the mooring in the heart of the Perl

[reply]

Back to Seekers of Perl Wisdom