Skip Menu |

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

Report information
The Basics
Id: 19857
Status: resolved
Priority: 0/
Queue: Module-Pluggable

People
Owner: simonw [...] cpan.org
Requestors: chris+rt [...] chrisdolan.net
Cc:
AdminCc:

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



Subject: Mistakenly including non .pm files when using require => 1
When using the "use Module::Pluggable require => 1", M::B mistakenly returns directories from the plugins() method. This is a regression from v2.97 and is causing test failures in Perl::Critic. Here's a simplified test case that demonstrates the problem: % mkdir -p lib/Foo/Plugin/Subdir % cat > lib/Foo.pm package Foo; use Module::Pluggable; print "$_\n" for plugins(); 1; % cat > lib/Foo/Plugin/Subdir/Bar.pm package Foo::Plugin::Subdir::Bar; 1; % perl -Ilib -e 'use Foo' Foo::Plugin::Subdir::Bar % cat >! lib/Foo.pm package Foo; use Module::Pluggable require => 1; print "$_\n" for plugins(); 1; % perl -Ilib -e 'use Foo' Foo::Plugin::Subdir Foo::Plugin::Subdir::Bar The failure is that plugins() returns "Foo::Plugin::Subdir" in the latter case. I believe the bug is in Devel::InnerPackage. The following example demonstrates the spurious return of the subdir: % perl -Ilib -le'use Devel::InnerPackage;require Foo::Plugin::Subdir::Bar;print for Devel::InnerPackage::list_packages "Foo::Plugin";' Foo::Plugin::Subdir Foo::Plugin::Subdir::Bar This should instead return just "Foo::Plugin::Subdir::Bar", I believe. -- Chris
On Tue Jun 13 02:03:27 2006, guest wrote: Show quoted text
> When using the "use Module::Pluggable require => 1", M::B mistakenly > returns directories from the plugins() method. This is a regression > from v2.97 and is causing test failures in Perl::Critic.
The problem is caused by the change from 3.0 to 3.01 The big problem is that there's no way to tell (as far as I can see) between a 'virtual' package and a real package. So for example. package No; package No::Middle::Bit; There is no actual package 'No::Middle'. However, my fix for that breaks another test I have which is checking for package TA::C::A::I; sub foo { } package TA::C::A::I::A; sub foo { } package TA::C::A::I::A::B; sub foo { } 1; In which case it only returns the last one TA::C::A::I::A::B, no ::I or ::I::A I'm lookign at how to solve this now. Sorry :(
Simon, Thanks for the quick response. I discovered that setting "inner => 0" works around the bug, so we'll release a new Perl::Critic and that should make everything happy again on our end. Perhaps inner => 0 should be the default? Or is it too late for an API change of that magnitude? Chris
CC: undisclosed-recipients: ;
Subject: Re: [rt.cpan.org #19857] Mistakenly including non .pm files when using require => 1
Date: Tue, 13 Jun 2006 15:31:46 +0100
To: via RT <bug-Module-Pluggable [...] rt.cpan.org>
From: Simon Wistow <simon [...] thegestalt.org>
On Tue, Jun 13, 2006 at 10:04:26AM -0400, via RT said: Show quoted text
> Thanks for the quick response. I discovered that setting "inner => 0" > works around the bug, so we'll release a new Perl::Critic and that > should make everything happy again on our end.
Ok, that's good. Sorry to have caused so much trouble. Show quoted text
> Perhaps inner => 0 should be the default? Or is it too late for an API > change of that magnitude?
I think, probably, it's too late. Foolishly I was little lax about adding stuff into the M::P core when I started it and now it's a little too late. Possibly I might change it so that the default in Module::Pluggable is 1 but the default for Module::Pluggable::Object is 0 but I'm a little wary of that. Simon
Fixed in 3.10 I think