Re: 5.10.1-RC1, CPANPLUS, and Module::Build

demerphq <[email protected]>
Newsgroups gmane.comp.lang.perl.perl5.porters,gmane.comp.version-control.subversion.rapidsvn.devel
Message-ID <[email protected]>
2009/8/8 Jos I. Boumans <[email protected]>:
> Hi,
>
> On 8 Aug 2009, at 14:44, Elliot Shank wrote:
>
>> Attempting to install Perl::Critic 1.102 via CPANPLUS from 5.10.1-RC1
>> fails due to what CPANPLUS is doing with the Module::Build mention in
>> configure_requires.  This version of P::C was built with perl 5.10.0 and
>> M::B 0.34_02 (the same one included in 5.10.1).  M::B puts its own version
>> into configure_requires.  I've got CPANPLUS pointed at a minicpan, which,
>> obviously, only includes M::B 0.34.
>
>> Despite already having the correct version of M::B already installed,
>> CPANPLUS refuses to install P::C.  Important part of the CPANPLUS output:
>
>> [MSG] Extracted 'Perl::Critic' to
>> '/Users/elliot/opt/perl/perl-5.10/cpanplus/5.10.1/build/Perl-Critic-1.102'
>> [ERROR] This distribution depends on Module::Build, but the latest version
>> of Module::Build on CPAN (0.34) doesn't satisfy the specific version
>> dependency (0.3402). You may have to resolve this dependency manually.
>
> Notice that in your diagnostics, 2 different versions are mentioned. Once
> 0.34_02, once 0.3402.
> One has a _, the other does not.
>
> Here's what's going on:
>
> CPANPLUS fishes the version statement out of Module::Build using the same
> regex that EU::MM and similar
> tools use. M::B's version statement looks like this:
>
>  $VERSION = '0.34_02';
>  $VERSION = eval $VERSION;
>
> Version statements must be on one line to be picked up by these tools and
> this one is not.

I will just note that this is normal. You don't /want/ the two
$VERSION statements on the same line.

The reason is that you want the underbar in the distro name, and in
the normal EUMM "parse from file ..." behaviour you also end up with
the correct value in the META.yml and blah blah. However you do NOT
want the underbar in the string when it is evaluated in numeric
context, or you end up with a warning. So the eval goes on the next
line. That way anything "following the rules" gets the string version
/with/ underbar, yet the value is actually stored in memory as a pure
integer and thus can be used in numeric version inequality tests
without throwing warnings.

You can find this pattern in literally hundreds of modules. In fact it
is not uncommon to see things like:

$VERSION= 1.23;
$VERSION= eval $VERSION;

as once people get a bug report about numeric comparisons from beta
releases, they find this pattern, add the eval, and then never remove
it. That way you don't get bitten twice when you do the next dev
release.

> Here's what happens:
>
>  $ perl -le'$v="0.34_02";print eval $v'
>  0.3402
>
> And now, we've lost our _. Module::Build writes the non-_ version into
> Meta.yml, rather than the version
> CPANPLUS and EU::MM will see. P::C's Meta.yml holds:
>
>  configure_requires: Module::Build: 0.3402

And this is the bug. If MB is not parsing the file in the same way
EUMM does then It Is Doing It Wrong(tm).

cheers,
Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.