Skip Menu |

This queue is for tickets about the Module-Load-Conditional CPAN distribution.

Report information
The Basics
Id: 24624
Status: resolved
Priority: 0/
Queue: Module-Load-Conditional

People
Owner: Nobody in particular
Requestors: jleffler [...] earthlink.net
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Module::Load::Conditional 0.16 is MUCH better - but is still confused by a few versions
Date: Fri, 26 Jan 2007 21:36:12 -0800
To: Bugs in Module-Load-Conditional via RT <bug-Module-Load-Conditional [...] rt.cpan.org>
From: Jonathan Leffler <jleffler [...] earthlink.net>
Module::Load::Conditional 0.16 is much, much better than the previous version -- thank you. On my system, a few modules are still showing up with confused version numbers: (output from 'o' in CPANPLUS: 1 3.00 3.000008 CIPP JRED 2 3.000014 3.000016 Class::DBI TMTM 3 3.0008 4.001 DBD::mysql CAPTTOFU 4 0.176 0.179 Email::Valid RJBS 5 1.0901 1.10 Errno GBARR 6 0.79 0.80 IPC::Run RSOD 7 0.62 0.63 Module::CPANTS::ProcessCPAN DOMM 8 0.92 0.93 PPM::Make::Util RKOBES 9 1.00 1.000005 Switch::Perlish BROQ 10 2.102 2.86 Template::Stash ABW 11 Unparsable 0.60 XMLRPC::Lite BYRNE ) I have miscellaneous build errorsthat are not germane to CPANPLUS or Module::Load::Conditional afflicting lines 2, 3, 4, 5, 6, 7; those are all fine. CIPP and Switch::Perlish are probably things that C::M::L should handle: Osiris JL: find perl -name CIPP.pm | xargs grep VERSION $VERSION = "3.0.8"; Osiris JL: find perl -name Perlish.pm | xargs grep VERSION $VERSION = '1.0.5'; =head1 VERSION Those two are probably quite readily curable. The joker in this pack is XMLRPC::Lite, which has the interesting version strings: Osiris JL: find perl -name Lite.pm | grep XMLRPC | xargs grep VERSION use vars qw($VERSION); #$VERSION = sprintf("%d.%s", map {s/_//g; $_} q$Name: $ =~ /-(\d+)_([\d_]+)/); $VERSION = $SOAP::Lite::VERSION; Using another modules version number as your own version number is pretty devious. I think I can submit that as something for the module author to fix. I'm more puzzled about the PPM::Make::Util version numbers, and the ones for Template::Stash (part of Template::Toolkit). The installed version is indeed P::M::U 0.92: find perl -name Util.pm | grep PPM/Make/U | xargs grep VERSION our $VERSION = '0.92'; The version of the file in PPM-Make-0.93 (extracted source) is also 0.92: find PPM-Make-0.93 -name Util.pm | xargs grep VERSION PPM-Make-0.93/blib/lib/PPM/Make/Util.pm:our $VERSION = '0.92'; ... PPM-Make-0.93/lib/PPM/Make/Util.pm:our $VERSION = '0.92'; ... So, how did the system in toto get to think the version should be 0.93? Similarly with Template::Toolkit: find Template-Toolkit-2.16 -name Stash.pm | xargs grep VERSION Template-Toolkit-2.16/blib/lib/Template/Stash.pm: our $VERSION = sprintf("%d.%02d", q$Revision: 2.102 $ =~ /(\d+)\.(\d+)/); It looks like M::L::C is determining the version correctly as 2.102, but somewhere else on CPAN has a fixation that 2.86 is more recent than 2.102. Could this be the problem of string vs numeric comparison for the part after the decimal point? -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/
On Sat Jan 27 00:37:13 2007, jleffler@earthlink.net wrote: Show quoted text
> Module::Load::Conditional 0.16 is much, much better than the previous > version -- thank you.
Thanks for testing, good to hear things are better now ;) Show quoted text
> On my system, a few modules are still showing up > with confused version numbers: > > (output from 'o' in CPANPLUS: > > 1 3.00 3.000008 CIPP JRED > 2 3.000014 3.000016 Class::DBI TMTM > 3 3.0008 4.001 DBD::mysql CAPTTOFU > 4 0.176 0.179 Email::Valid RJBS > 5 1.0901 1.10 Errno GBARR > 6 0.79 0.80 IPC::Run RSOD > 7 0.62 0.63 Module::CPANTS::ProcessCPAN DOMM > 8 0.92 0.93 PPM::Make::Util RKOBES > 9 1.00 1.000005 Switch::Perlish BROQ > 10 2.102 2.86 Template::Stash ABW > 11 Unparsable 0.60 XMLRPC::Lite BYRNE > > ) > > I have miscellaneous build errorsthat are not germane to CPANPLUS or > Module::Load::Conditional afflicting lines 2, 3, 4, 5, 6, 7; those are > all fine. > > CIPP and Switch::Perlish are probably things that C::M::L should handle: > > Osiris JL: find perl -name CIPP.pm | xargs grep VERSION > $VERSION = "3.0.8"; > Osiris JL: find perl -name Perlish.pm | xargs grep VERSION > $VERSION = '1.0.5'; > =head1 VERSION
They are already handled, and handled correctly by M::L::C. What you see in our 'o' output is simply a representation as CPANPLUS has chosen it for x.y.z style version numbers (done by C::Shell::Default->_format_version): ### allow 6 digits after the dot, as that's how perl stringifies ### x.y.z numbers. $version = sprintf('%3.6f', $version); In this case '3.0.8' becomes '3.000008', both for graphical representation and possibly numeric comparison.. This is analogous as to how perl itself does it: $ perl -le'print $]' 5.008006 Show quoted text
> The joker in this pack is XMLRPC::Lite, which has the interesting > version strings: > > Osiris JL: find perl -name Lite.pm | grep XMLRPC | xargs grep VERSION > use vars qw($VERSION); > #$VERSION = sprintf("%d.%s", map {s/_//g; $_} q$Name: $ =~ > /-(\d+)_([\d_]+)/); > $VERSION = $SOAP::Lite::VERSION;
I'm not able to find the docs on it (which of course is bad), but at least EU::MM has a reference to it; All parsable version declarations *must* be on a single line. In this case, it is not. The correct way for M::L::C (or EU::MM, or any other known tool for that matter) to parse this correctly would be something along the lines of: $VERSION = do { require SOAP::Lite; $SOAP::Lite::VERSION }; See the 'VERSION_FROM' section in the EU::MM docs for details: http://search.cpan.org/~mschwern/ExtUtils-MakeMaker-6.31/lib/ExtUtils/ MakeMaker.pm#Using_Attributes_and_Parameters Show quoted text
> Using another modules version number as your own version number is > pretty devious. I think I can submit that as something for the module > author to fix.
I think indeed that's the way to go. Show quoted text
> I'm more puzzled about the PPM::Make::Util version numbers, and the ones > for Template::Stash (part of Template::Toolkit). > > The installed version is indeed P::M::U 0.92: > > find perl -name Util.pm | grep PPM/Make/U | xargs grep VERSION > our $VERSION = '0.92'; > > > The version of the file in PPM-Make-0.93 (extracted source) is also 0.92: > > find PPM-Make-0.93 -name Util.pm | xargs grep VERSION > PPM-Make-0.93/blib/lib/PPM/Make/Util.pm:our $VERSION = '0.92'; > ... > PPM-Make-0.93/lib/PPM/Make/Util.pm:our $VERSION = '0.92'; > ... > > So, how did the system in toto get to think the version should be 0.93?
That one's easy :) This is due to the 02packages.gz file we get from CPAN (the mirror) which tells us what versions of modules it has. A simple grep shows us: $ zcat 02packages.details.txt.gz |grep PPM::Make::Util PPM::Make::Util 0.93 R/RK/RKOBES/PPM-Make-0.93.tar.gz So that's where the 0.93 comes from. Show quoted text
> Similarly with Template::Toolkit: > > find Template-Toolkit-2.16 -name Stash.pm | xargs grep VERSION > Template-Toolkit-2.16/blib/lib/Template/Stash.pm: > our $VERSION = sprintf("%d.%02d", q$Revision: 2.102 $ =~ /(\d+)\.(\d+)/);
And similar answer,.. 02packages shows us: Template::Stash 2.86 A/AB/ABW/Template-Toolkit-2.14.tar.gz Show quoted text
> It looks like M::L::C is determining the version correctly as 2.102, but > somewhere else on CPAN has a fixation that 2.86 is more recent than > 2.102. Could this be the problem of string vs numeric comparison for > the part after the decimal point?
No 'string vs numerical' here.. they both look like floats, and if you do a simple comparison, you see that 2.86 is the 'newer' one: $ perl -le'print 1 if 2.86 > 2.102' 1 Which is exactly what happens here... If this was intended as a x.y.z version where 2 == 2 and 102 > 86, most tools will actually not handle this correctly. at least a x.y.z version should be used, rather than x.y; so 2.102.0 vs 2.86.0: $ perl -le'print 1 if sprintf("%3.6f","2.102.0") > sprintf("%3.6f","2.086.0")' 1 Hopefully this clears matters up somewhat ;) Thanks again for reporting, Jos