Skip Menu |

This queue is for tickets about the ExtUtils-MakeMaker CPAN distribution.

Report information
The Basics
Id: 30747
Status: resolved
Priority: 0/
Queue: ExtUtils-MakeMaker

People
Owner: mschwern [...] cpan.org
Requestors: Marek.Rouchal [...] gmx.net
Cc:
AdminCc:

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



Subject: CPAN fails to read version from some modules during r command
I verified that ExtUtils::MakeMaker is running OK: /opt/perl_5.8.8/bin/perl -Mversion -MExtUtils::MakeMaker -e 'print ExtUtils::MakeMaker->new->parse_version ("/opt/perl_5.8.8/lib/Module/ExtractUse.pm")' Warning: Guessing NAME [Perl] from current directory name. 0.20 (0.20 is the version of the installed Module::ExtractUse) But when I am running in the CPAN shell the 'r' command, it chokes on this line from /opt/perl_5.8.8/lib/Module/ExtractUse.pm: use version; our $VERSION=version->new('0.20'); The complete error message is (I copy/pasted two lines of context of the output of the 'r' command): Module::CPANTS::Analyse undef 0.75 DOMM/Module-CPANTS- Analyse-0.75.tar.gz Could not eval ' package ExtUtils::MakeMaker::_version; no strict; BEGIN { eval { require version; "version"->import; } } local $VERSION; $VERSION=undef; do { use version; our $VERSION=version->new('0.21'); }; $VERSION ' in /opt/perl_5.8.8/lib/Module/ExtractUse.pm: Can't call method "new" on an undefined value at (eval 1311) line 11, <FH> line 10. Could not eval ' package ExtUtils::MakeMaker::_version; no strict; BEGIN { eval { require version; "version"->import; } } local $VERSION; $VERSION=undef; do { use version; our $VERSION=version->new('0.21'); }; $VERSION ' in /opt/perl_5.8.8/lib/Module/ExtractUse.pm: Can't call method "new" on an undefined value at (eval 1312) line 11, <FH> line 10. Module::ExtractUse undef 0.21 DOMM/Module-ExtractUse- 0.21.tar.gz It seems strange that the ExtUtils::MakeMaker::MM_Unix->parse_version method is called twice, and cannot interpret the code. Does CPAN do any tweaking of the 'version' name? This happens here on my perl-5.8.8, both on Solaris 8 (Sparc) and RedHat Enterprise Linux 3.0 (x86). Please let me know if you need any additional information. Cheers, Marek
Subject: Re: [rt.cpan.org #30747] CPAN fails to read version from some modules during r command
Date: Fri, 16 Nov 2007 05:04:06 +0100
To: bug-CPAN [...] rt.cpan.org
From: andreas.koenig.7os6VVqR [...] franz.ak.mind.de (Andreas J. Koenig)
Show quoted text
>>>>> On Thu, 15 Nov 2007 03:44:51 -0500, "Marek Rouchal via RT" <bug-CPAN@rt.cpan.org> said:
Show quoted text
> Please let me know if you need any additional information.
I cannot reproduce this here on my Debian box with my bleadperl@32308 with: cpan[4]> m version Module id = version DESCRIPTION structured version objects CPAN_USERID JPEACOCK (John Peacock <jpeacock@cpan.org>) CPAN_VERSION 0.74 CPAN_FILE J/JP/JPEACOCK/version-0.74.tar.gz UPLOAD_DATE 2007-10-25 DSLIP_STATUS MdhOp (mature,developer,hybrid,object-oriented,Standard-Perl) MANPAGE version - Perl extension for Version Objects INST_FILE /home/src/perl/repoperls/installed-perls/perl/pV3imXl/perl-5.8.0@32308/lib/5.10.0/version.pm INST_VERSION 0.74 cpan[5]> m ExtUtils::MakeMaker Module id = ExtUtils::MakeMaker DESCRIPTION Writes Makefiles for extensions CPAN_USERID MMML (The MakeMaker mailing list <makemaker@perl.org>) CPAN_VERSION 6.36 CPAN_FILE M/MS/MSCHWERN/ExtUtils-MakeMaker-6.36.tar.gz UPLOAD_DATE 2007-07-03 DSLIP_STATUS SupO? (standard,comp.lang.perl.*,perl,object-oriented,) MANPAGE ExtUtils::MakeMaker - Create a module Makefile INST_FILE /home/src/perl/repoperls/installed-perls/perl/pV3imXl/perl-5.8.0@32308/lib/5.10.0/ExtUtils/MakeMaker.pm INST_VERSION 6.36_01 I cannot reproduce either with my 5.8.8: cpan[3]> m version CPAN: LWP::UserAgent loaded ok (v2.036) CPAN: URI::URL loaded ok (v5.03) Module id = version DESCRIPTION structured version objects CPAN_USERID JPEACOCK (John Peacock <jpeacock@cpan.org>) CPAN_VERSION 0.74 CPAN_FILE J/JP/JPEACOCK/version-0.74.tar.gz UPLOAD_DATE 2007-10-25 DSLIP_STATUS MdhOp (mature,developer,hybrid,object-oriented,Standard-Perl) MANPAGE version - Perl extension for Version Objects INST_FILE /usr/local/perl-5.8.8/lib/site_perl/5.8.8/i686-linux-64int/version.pm INST_VERSION 0.7203 cpan[4]> m ExtUtils::MakeMaker Module id = ExtUtils::MakeMaker DESCRIPTION Writes Makefiles for extensions CPAN_USERID MMML (The MakeMaker mailing list <makemaker@perl.org>) CPAN_VERSION 6.36 CPAN_FILE M/MS/MSCHWERN/ExtUtils-MakeMaker-6.36.tar.gz UPLOAD_DATE 2007-07-03 DSLIP_STATUS SupO? (standard,comp.lang.perl.*,perl,object-oriented,) MANPAGE ExtUtils::MakeMaker - Create a module Makefile INST_FILE /usr/local/perl-5.8.8/lib/5.8.8/ExtUtils/MakeMaker.pm INST_VERSION 6.36 And I have tried a recent install of the maint-5.8 branch @32273. Works fine here too: cpan[3]> m version Module id = version DESCRIPTION structured version objects CPAN_USERID JPEACOCK (John Peacock <jpeacock@cpan.org>) CPAN_VERSION 0.74 CPAN_FILE J/JP/JPEACOCK/version-0.74.tar.gz UPLOAD_DATE 2007-10-25 DSLIP_STATUS MdhOp (mature,developer,hybrid,object-oriented,Standard-Perl) MANPAGE version - Perl extension for Version Objects INST_FILE /home/src/perl/repoperls/installed-perls/maint-5.8/p9MYFdQ/perl-5.8.0@32273/lib/site_perl/5.8.8/i686-linux-64int/version.pm INST_VERSION 0.74 cpan[4]> m ExtUtils::MakeMaker Module id = ExtUtils::MakeMaker DESCRIPTION Writes Makefiles for extensions CPAN_USERID MMML (The MakeMaker mailing list <makemaker@perl.org>) CPAN_VERSION 6.36 CPAN_FILE M/MS/MSCHWERN/ExtUtils-MakeMaker-6.36.tar.gz UPLOAD_DATE 2007-07-03 DSLIP_STATUS SupO? (standard,comp.lang.perl.*,perl,object-oriented,) MANPAGE ExtUtils::MakeMaker - Create a module Makefile INST_FILE /home/src/perl/repoperls/installed-perls/maint-5.8/p9MYFdQ/perl-5.8.0@32273/lib/5.8.8/ExtUtils/MakeMaker.pm INST_VERSION 6.36 All three have Module::ExtractUse installed. All three see 0.21 in the index and report the upgrade line as they should: Module::ExtractUse 0.20 0.21 DOMM/Module-ExtractUse-0.21.tar.gz Please let me know if you find additional evidence. At the moment I have no idea where to look. -- andreas
Subject: RE: [rt.cpan.org #30747] CPAN fails to read version from some modules during r command
Date: Fri, 16 Nov 2007 11:11:07 +0100
To: <bug-CPAN [...] rt.cpan.org>, <mschwern [...] cpan.org>, <dsb [...] cpan.org>
From: <marek.rouchal [...] infineon.com>
Hi Andreas, and Michael, David, thanks for the encouraging note - I found the culprit: /opt/perl_5.8.8/lib/IPC/ClearTool.pm:$VERSION = "3.16"; sub version {$VERSION} When this is eval'ed by MM->parse_version, it leaves the sub version { $VERSION } in the ExtUtils::MakeMaker::_version package, and when e.g. Module::ExtractUse's use version; our $VERSION = version->new('0.21'); is eval'ed, the error occurs since 'version' is taken to be a sub (returning the undef from $VERSION), not a class name. Hence the error messages that I am seeing. What can we do? David, would you change the $VERSION line in IPC::ClearTool, and break it into two, like this: $VERSION = "3.17"; sub version {$VERSION} or - even better - drop the "version" sub completely, since any user that uses IPC::ClearTool and the "version" module together may run into similar problems? Michael (and maybe Andreas): I'm not sure whether there is a robust way to either strip a sub version { ... } from the "$VERSION" line which is parsed in MM->parse_version, or whether a version->new could be translated into a "version"->new to protect against an eventual "sub version", like in the BEGIN { "version"->import }. Or, one more idea, just like you say "local($VERSION) = undef", why not undef &version; or even undef *version; # is that legal? before eval'ing the $VERSION line? Hope this helps, Marek
Fixed in the repo. Will be in 6.37.
CC: bug-CPAN [...] rt.cpan.org, dsb [...] cpan.org
Subject: Re: [rt.cpan.org #30747] CPAN fails to read version from some modules during r command
Date: Fri, 16 Nov 2007 12:21:59 -0800
To: marek.rouchal [...] infineon.com
From: Michael G Schwern <schwern [...] pobox.com>
marek.rouchal@infineon.com wrote: Show quoted text
> thanks for the encouraging note - I found the culprit: > > /opt/perl_5.8.8/lib/IPC/ClearTool.pm:$VERSION = "3.16"; sub version > {$VERSION} > > When this is eval'ed by MM->parse_version, it leaves the > sub version { $VERSION } > in the ExtUtils::MakeMaker::_version package, and when > e.g. Module::ExtractUse's > use version; our $VERSION = version->new('0.21'); > is eval'ed, the error occurs since 'version' is taken > to be a sub (returning the undef from $VERSION), not a > class name. Hence the error messages that I am seeing.
Thanks, that's an excellent bit of sleuthing. I can reproduce it in the MakeMaker tests. Show quoted text
> Or, one more idea, just like > you say "local($VERSION) = undef", why not > undef &version; > or even > undef *version; # is that legal? > before eval'ing the $VERSION line?
I took this approach. The more radical approach would be to create a new temp package for each parse_version() call but I fear the memory bloat. That said, IPC::ClearTool should still move "sub version" to it's own line to avoid this in existing MakeMaker versions. --- lib/ExtUtils/MM_Unix.pm (revision 40783) +++ lib/ExtUtils/MM_Unix.pm (local) @@ -2717,12 +2722,17 @@ package ExtUtils::MakeMaker::_version; no strict; BEGIN { eval { + # Ensure any version() routine which might have leaked + # into this package has been deleted. Interferes with + # version->import() + undef *version; require version; "version"->import; } } local $1$2; - \$$2=undef; do { + \$$2=undef; + do { $_ }; \$$2 }; -- The interface should be as clean as newly fallen snow and its behavior as explicit as Japanese eel porn.
Hi - sorry, I just saw the email on this addressed to me as it was caught in my spam filter (unfortunately the great majority of mail to my CPAN account is in fact spam). Sorry about the unfortunately named and placed version sub. I'd be happy to remove it in a new version - the only problem is that IPC::ClearTool is mature, aka dead. I haven't updated it since 2004 and have declared it obsolete in the appropriate fora. In fact I've been thinking of removing it from CPAN. Thus I don't particularly want to issue a new version as that would send a confusing/wrong signal to users. So, if seems to be the case, a fix has been made, I think I'll either leave it as-is or accelerate the transition of IPC::ClearTool to backpan.
On Wed Nov 28 23:33:00 2007, DSB wrote: Show quoted text
> Hi - sorry, I just saw the email on this addressed to me as it was > caught in my spam filter (unfortunately the great majority of mail to my > CPAN account is in fact spam). > > Sorry about the unfortunately named and placed version sub. I'd be happy > to remove it in a new version - the only problem is that IPC::ClearTool > is mature, aka dead. I haven't updated it since 2004 and have declared > it obsolete in the appropriate fora. In fact I've been thinking of > removing it from CPAN. Thus I don't particularly want to issue a new > version as that would send a confusing/wrong signal to users. > > So, if seems to be the case, a fix has been made, I think I'll either > leave it as-is or accelerate the transition of IPC::ClearTool to backpan.
Yep, the fix has been made so you're free to do whatever you like with IPC::ClearTool.