Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

What is the impact of 5.18.0?

by Tux (Monsignor)
on May 19, 2013 at 10:53 UTC ( #1034206=perlmeditation: print w/ replies, xml ) Need Help??

I use my laptop as test environment. When all (upgrades) pass on production/utility software, I upgrade my workstation. If that shows no problems after a few weeks, I start upgrading other production servers.

So I installed 5.18.0 on my laptop as default perl, and then tried to install all CPAN modules I ever used in 5.16.x

There are just a few things that stand out as a reason for FAILure:

  • Test files that use for $foo qw( ) { which is now deprecated. The module autor should rewrite that to for $foo (qw( )) {. I filed RT tickets for all I encountered. Lets hope the authors will fix their code.
  • POD failures. As the POD checker is now way stricter than the old version was, it shows more real trouble. And it should! The problem is that many authors ship the pod tests too, so the test suite will fail if Test::Pod and friends are installed, and thus cpan won't install those modules. That means manual work ignoring the pod errors (and when obvious file RT tickets). Authors: unless you keep in sync with reality and release often, please do not include pod tests in you distribution.
  • Loads of warnings when a module uses given/when as those are now marked experimental. I can ignore the warnings when testing, but will they fill up my logs when run in production code? When the module also uses Test::NoWarnings, one cannot install. A module like MooseX::App now won't install, and it causes many other modules that have this as a prerequisite to fail too.
  • XS authors that never updated ppport.h from Devel::PPPort. Easy to fix.
  • Modules that use Module::Install but ship ancient or incomplete versions of it in inc. The easiest solution for me was to just recursively remove inc/ and all problems vanish. I have no tuits to RT all of them.
  • Several modules fail because they declare optional deps that are actually hard deps, like using JSON::XS, Lexical::Sub or Data::Alias - which won't build under 5.18.0
  • Test failures, or maybe even code failures, due to hash randomization. Unless I am absolutely sure that the test is wrong, I cannot install these modules.
  • Some failures have been reported to the authors but the available fix has not (yet) been applied (like in Template::Toolkit RT#84778) or not yet released (Tk and SQL::Statement). When their repository is open, they build fine from the repo and I am confident the next release will build fine.

The message is: perl-5.18.0 is awesome, but please please test the module you require before starting the installation on machines other than a test environment.


Enjoy, Have FUN! H.Merijn

Comment on What is the impact of 5.18.0?
Select or Download Code
Re: What is the impact of 5.18.0?
by tobyink (Abbot) on May 19, 2013 at 11:13 UTC

    I'm using 5.18.0 as my main development Perl already.

    Lexical subs seem like they'll be a nice new feature, but it'll probably be some time before they're suitable for production code.

    That said, Perl 5.18 seems to have brought more upgrade annoyances than Perl 5.16 did. Introducing warnings for smart match is annoying. Especially when they're difficult to disable. (no warnings "experimental::smartmatch"; seems easy, but dies in older versions of Perl, so you need something like no if $] >= 5.018, warnings => "experimental::smartmatch";.). Yet another annoyance with warnings.pm that makes me wonder why I bother enabling warnings to begin with (strict catches far more errors than warnings ever does).

    package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name
      no if $] >= 5.018, warnings => "experimental::smartmatch";

      I'm surprised at this syntax for a conditional no. Is it documented somewhere?

      Update: Ah, I found it in use.

      -QM
      --
      Quantum Mechanics: The dreams stuff is made of

        :) perldoc -f no
        perldoc if

      Instead of turning off all warnings, you can just disable the experimental ones with:

      no if $] >= 5.018, warnings => "experimental";

      While I don't necessarily advocate this course of action, I think it would be preferable to a general "no warnings;".

      -- Ken

Re: What is the impact of 5.18.0?
by Anonymous Monk on May 19, 2013 at 17:17 UTC

    so the test suite will fail if Test::Pod and friends are installed,

    And here i though pod tests were AUTHOR tests that shouldn't affect installations one way or the other :)

      It's a bad idea to run pod tests at the user end, but nevertheless some distributions do.

      package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name

      The CPANTS kwalitee scanner had a metric for using Test::Pod directly for the longest time. That's a lot of inertia to overcome.

        Authors: unless you keep in sync with reality and release often, please do not include pod tests in you distribution.

        You are right, but authors that actively partition in the CPANTS game most likely ar willing to either fix their pod (best solution) or move to xt/.


        Enjoy, Have FUN! H.Merijn
Re: What is the impact of 5.18.0?
by kcott (Abbot) on May 26, 2013 at 04:17 UTC

    A further annoyance with the experimental features is that "use 5.018;" only enables some of them (e.g. 'smartmatch' is enabled while 'lexical_subs' is not). In addition, it would be useful if the error or warning messages actually stated what the related feature was (or vice versa).

    Here's some examples.

    This produces warnings about given and when (you need to know that the feature is smartmatch) and an error about "my" subs (you need to know that the feature is lexical_subs):

    $ perl -Mstrict -Mwarnings -e ' use 5.018; my ($x, $y) = (1, undef); given ($x) { when (1) { say "\$x == 1" } default { say "\$x != 1" } } given ($y) { when (1) { say "\$y == 1" } default { say "\$y != 1" } } my sub z { say "In z()" } z(); ' given is experimental at -e line 4. when is experimental at -e line 5. given is experimental at -e line 8. when is experimental at -e line 9. Experimental "my" subs not enabled at -e line 12.

    Also potentially confusing, is that the warnings are not emitted if the error is emitted first:

    $ perl -Mstrict -Mwarnings -e ' use 5.018; my sub z { say "In z()" } my ($x, $y) = (1, undef); given ($x) { when (1) { say "\$x == 1" } default { say "\$x != 1" } } given ($y) { when (1) { say "\$y == 1" } default { say "\$y != 1" } } z(); ' Experimental "my" subs not enabled at -e line 3.

    Enabling lexical_subs in the first example, the code runs but with lots of warnings. Note the warnings inconsistency of given/when mentioning the code but not the feature and lexical_subs mentioning the feature but not the code (which, in itself, is inconsistent with the lexical_subs error mentioning the code but not the feature):

    $ perl -Mstrict -Mwarnings -e ' use 5.018; use feature "lexical_subs"; my ($x, $y) = (1, undef); given ($x) { when (1) { say "\$x == 1" } default { say "\$x != 1" } } given ($y) { when (1) { say "\$y == 1" } default { say "\$y != 1" } } my sub z { say "In z()" } z(); ' given is experimental at -e line 5. when is experimental at -e line 6. given is experimental at -e line 9. when is experimental at -e line 10. The lexical_subs feature is experimental at -e line 13. $x == 1 $y != 1 In z()

    Adding 2 more lines of code to get rid of the warnings:

    $ perl -Mstrict -Mwarnings -e ' use 5.018; use feature "lexical_subs"; no if $] >= 5.018, warnings => "experimental::smartmatch"; no if $] >= 5.018, warnings => "experimental::lexical_subs"; my ($x, $y) = (1, undef); given ($x) { when (1) { say "\$x == 1" } default { say "\$x != 1" } } given ($y) { when (1) { say "\$y == 1" } default { say "\$y != 1" } } my sub z { say "In z()" } z(); ' $x == 1 $y != 1 In z()

    [In the above examples, replacing -e with -E and removing use 5.018; produces the same result.]

    While something of a contrived point, I do note that the additional code I had to add in order to remove all of the warnings is of an equivalent size to the warnings themselves.

    -- Ken

Re: What is the impact of 5.18.0?
by smls (Friar) on May 31, 2013 at 20:26 UTC

    After upgrading to 5.18.0, I too was annoyed by the dev's decision to now make use warnings now also spam "Smartmatch is experimental" messages, since I used given/when/~~ in some of my scripts.

    But after more research, it seems there is a good reason for those messages. From perlbug #116913: experimental warning for given/~~ before 5.20.0:

    The behavior of given/when/~~ are likely to change in perl 5.20.0: either smart match will be removed or stripped down. In light of this, users of these features should be warned.

    So it seems the annoyance is intended, to motivate us to phase out the usage of those features in our scripts.
    Still, I think the point would have come across more clearly if the warning would read "Smartmatch is deprecated" instead of "experimental"...

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (7)
As of 2014-09-20 20:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (163 votes), past polls