Re: 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...

Comment on Re: Chasing up a module dependency issue Select or Download Code

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]
Re^3: Chasing up a module dependency issue by Corion (Patriarch) on Mar 07, 2016 at 18:32 UTC
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]
Re^4: Chasing up a module dependency issue by cLive ;-) (Prior) on Mar 07, 2016 at 18:57 UTC
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]


The stupid question is the question not asked
	PerlMonks