http://qs321.pair.com?node_id=1157013


in reply to Chasing up a module dependency issue

I think this comes from a module that uses (resp. inherits from) Exporter and where Module::Name->import is called with method_name as argument. The simplest case would be:

use Module::Name 'method_name';

[download]

... but that's likely too obvious and you've tried that already. A more contrived way would be something like:

my $module = 'Module::Name';
require 'Module/Name.pm';
$module->import('method_name');

[download]

Maybe (maybe) your code is picking up the wrong versions of Module::Name somewhere else in @INC? Dumping \%INC might tell you which version got picked up.

The easiest "fix" in my opinion would be to preload all the relevant modules at the very top of your program:

#!perl -w
use strict;
use Module::A;
use Module::B;
use Module::Name 'method_name';

...

[download]

That way, all the modules should be loaded in the correct order...

Replies are listed 'Best First'.
Re^2: Chasing up a module dependency issue
by cLive ;-) (Prior) on Mar 07, 2016 at 16:28 UTC
    use Module::Name 'method_name';

    That is what I think the issue is

    The code appears to work as a whole, under mod_perl, but it's failing the unit tests (that have finally been added to the code recently :)

    What I'm trying to work out is what exactly would cause the wiping out of the @EXPORT_OK. I thought that was scoped to the current package? Or is the error indicative of another issue?

    I really don't want to have to comb through the entire code base, if avoidable. On a hunch, I tried to switch @EXPORT_OK to @EXPORT, but that doesn't appear to have done anything = though mayne I need to look in the spiderweb of module includes and tweak all instances for it to work?

[reply]
[d/l]

      What you describe shouldn't happen, for the reasons you describe as well. Maybe the unit tests do something weird, or maybe you use use_ok, which can fail (for example due to a syntax error) but the test script itself will continue with a half-compiled module. I fear that this is not really debuggable from afar and mostly tied to your specific source code situation at work...

      Maybe putting a callback into @INC allows you to debug what modules get loaded when, to narrow down the files after which problematic things happen:

      push @INC, sub { print "Loading @_\n"; return () };

      [download]

      Maybe one of the modules contains a (second) package declaration that matches one found earlier and overwrites something in another package?

[reply]
[d/l]
[select]

        It's only used in two places - I think I'm just going to remove Exporter completely (I hate imported methods anyway, heh).

        The scales that weigh up the balance of how interesting it would be to fully understand and getting on with my day are heavily swaying to the latter ;-)

[reply]

In Section Seekers of Perl Wisdom