Bug #92989 for Module-Runtime: bad if statement causes use_module() and use_package

Thu Feb 13 04:38:59 2014 IDOPEREL [...] cpan.org - Ticket created

Subject:

bad if statement causes use_module() and use_package_optimistically() to fail

In version 0.014 the "use_module()" and "use_package_optimistically()" methods changed their test for the "$version" variable from "if defined $version" to "if @_ >= 2". This causes quite a few CPAN modules to fail because for some reason "undef" is passed for "$version". This breaks anything from small scripts to entire systems I have who rely on a lot of CPAN modules. Since it's third party CPAN modules who pass those renegade undefs, it is not in my power to fix it. Besides, I think the previous if statement made much more sense. Thanks.

Thu Feb 13 04:55:14 2014 zefram [...] fysh.org - Correspondence added

Subject:	Re: [rt.cpan.org #92989] bad if statement causes use_module() and use_package_optimistically() to fail
Date:	Thu, 13 Feb 2014 09:54:57 +0000
To:	Ido Perelmutter via RT <bug-Module-Runtime [...] rt.cpan.org>
From:	Zefram <zefram [...] fysh.org>

Ido Perelmutter via RT wrote: Show quoted text

>In version 0.014 the "use_module()" and "use_package_optimistically()" >methods changed their test for the "$version" variable from "if defined >$version" to "if @_ >= 2".

This change was a bugfix. Those functions are documented to perform a version check if the version paramater is supplied, not if it's supplied and not undef. It is not M:R's business to prejudge what a module will accept as a version number to test against. The modules that pass undef for the version parameter are buggy, and always were. They need to stop passing a version parameter when they don't want a version check. The module authors are not totally to blame, of course: they've been misled by the previous buggy behaviour of M:R. But these bugs need to be fixed. It is best that M:R get strict at the earliest possible opportunity, now, to avoid breeding more of these bugs that would cause more pain when M:R gets fixed later. If you let me know which CPAN modules are affected, I'll happily help patch them. For your purposes, you can apply patches to them via distroprefs. -zefram

Thu Feb 13 04:55:14 2014 The RT System itself - Status changed from 'new' to 'open'

Wed Feb 26 06:12:10 2014 ovid [...] cpan.org - Correspondence added

On Thu Feb 13 04:55:14 2014, zefram@fysh.org wrote: Show quoted text

> Ido Perelmutter via RT wrote:

> >In version 0.014 the "use_module()" and "use_package_optimistically()" > >methods changed their test for the "$version" variable from "if defined > >$version" to "if @_ >= 2".

> > This change was a bugfix. Those functions are documented to perform a > version check if the version paramater is supplied, not if it's supplied > and not undef. It is not M:R's business to prejudge what a module will > accept as a version number to test against.

May I suggest that as a workaround, it simply carps very loudly instead of killing production systems, then? Moose versions 2.1202 and earlier (I'm not sure if all versions are impacted) now fail if you do this: "perl -MMoose -e 1". Now companies relying on Moose are in an interesting situation: upgrade Moose or downgrade Module::Runtime. If I were in a production environment and critical systems are failing, I'd probably do a local monkey patch to Module::Runtime and trap the failure, ensuring that even if Module::Runtime were upgraded, I wouldn't use the lethal CPAN version. Breaking people's production code isn't a good thing. Cheers, Ovid

Wed Feb 26 06:20:13 2014 ovid [...] cpan.org - Correspondence added

Oh, and embedding the module name in the error message would help, too. Cheers, Ovid

Fri Jul 04 14:50:37 2014 ether [...] cpan.org - Cc ETHER added

Wed Sep 09 18:23:19 2015 ether [...] cpan.org - Correspondence added

On 2014-02-26 03:12:10, OVID wrote: Show quoted text

> Moose versions 2.1202 and earlier (I'm not sure if all versions are impacted) now fail if you do this: "perl -MMoose -e 1". Now companies relying on Moose are in an interesting situation: upgrade Moose or downgrade Module::Runtime

For people who come to this issue looking for details of the Moose issue: this was fixed in Moose 2.1203/2.1204 (February 2014), and can also be checked in your system by installing Module::Runtime::Conflicts; running `moose-outdated` will let you know of any Moose-related modules that need updating as a result of this interface change in Module::Runtime.

Sun May 07 09:51:09 2017 perl [...] toby.ink - Correspondence added

On 2014-02-13T09:55:14Z, zefram@fysh.org wrote: Show quoted text

> This change was a bugfix. Those functions are documented to perform a > version check if the version paramater is supplied, not if it's supplied > and not undef. It is not M:R's business to prejudge what a module will > accept as a version number to test against.

For what it's worth, this is actually inconsistent with Perl's built-in `use` implementation: perl -e'BEGIN{package Foo;$INC{"Foo.pm"}=__FILE__;use Data::Dumper;sub VERSION{print "VERSION\n",Dumper(@_)}sub import{print "import\n", Dumper(@_)}}; use Foo 1' Output: VERSION $VAR1 = 'Foo'; $VAR2 = 1; import $VAR1 = 'Foo'; perl -e'BEGIN{package Foo;$INC{"Foo.pm"}=__FILE__;use Data::Dumper;sub VERSION{print "VERSION\n",Dumper(@_)}sub import{print "import\n", Dumper(@_)}}; use Foo 1' Output: import $VAR1 = 'Foo'; $VAR2 = undef; So when `use Module undef` is encountered by Perl, MODULE->VERSION(undef) is *not* called.

Sun May 07 10:43:11 2017 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Sun May 07 09:51:09 2017, TOBYINK wrote: Show quoted text

> On 2014-02-13T09:55:14Z, zefram@fysh.org wrote:

> > This change was a bugfix. Those functions are documented to perform > > a > > version check if the version paramater is supplied, not if it's > > supplied > > and not undef. It is not M:R's business to prejudge what a module > > will > > accept as a version number to test against.

> > For what it's worth, this is actually inconsistent with Perl's built- > in `use` implementation: > > perl -e'BEGIN{package Foo;$INC{"Foo.pm"}=__FILE__;use Data::Dumper;sub > VERSION{print "VERSION\n",Dumper(@_)}sub import{print "import\n", > Dumper(@_)}}; use Foo 1' > > Output: > > VERSION > $VAR1 = 'Foo'; > $VAR2 = 1; > import > $VAR1 = 'Foo'; > > > perl -e'BEGIN{package Foo;$INC{"Foo.pm"}=__FILE__;use Data::Dumper;sub > VERSION{print "VERSION\n",Dumper(@_)}sub import{print "import\n", > Dumper(@_)}}; use Foo 1'

I think you meant ‘use Foo undef’ there. Show quoted text

> > Output: > > import > $VAR1 = 'Foo'; > $VAR2 = undef; > > > So when `use Module undef` is encountered by Perl, MODULE-

> >VERSION(undef) is *not* called.

This is unrelated. Whether VERSION is called has nothing to do with whether what follows the module name is defined. It has to do with whether it looks like a version number. ‘use Foo "3"' also does not call VERSION, but that does not mean Module::Runtime should reject "3" as a version.

Fri Aug 11 19:21:02 2017 ZEFRAM [...] cpan.org - Status changed from 'open' to 'rejected'

Bug #92989 for Module-Runtime: bad if statement causes use_module() and use_package_optimistically() to fail