Changing @INC before use'ing a module in a BEGIN block

ig has asked for the wisdom of the Perl Monks concerning the following question:

Can someone please explain why the following doesn't work?

#!/usr/bin/perl
#
use strict;
use warnings;

BEGIN {
    @INC = ( "/opt/app/lib" );
    use Application::Module;
}
[download]

It fails with:

Can't locate Application/Module.pm in @INC (@INC contains: /usr/lib/pe
+rl5/site_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/site_perl/
+5.8.7/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.6/i386-lin
+ux-thread-multi /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-mult
+i /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl/5.8.7 /usr/
+lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/per
+l5/site_perl /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi
+ /usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi /usr/lib/pe
+rl5/vendor_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/vendor_p
+erl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /u
+sr/lib/perl5/vendor_perl/5.8.7 /usr/lib/perl5/vendor_perl/5.8.6 /usr/
+lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl /usr/lib/perl5
+/5.8.8/i386-linux-thread-multi /usr/lib/perl5/5.8.8 .) at ./test2.pl 
+line 8.
BEGIN failed--compilation aborted at ./test2.pl line 8.
[download]

Both the following work:

#!/usr/bin/perl
#
use strict;
use warnings;

BEGIN {
    @INC = ( "/opt/app/lib" );
    eval "use Application::Module";
}
[download]

#!/usr/bin/perl
#
use strict;
use warnings;

BEGIN {
    @INC = ( "/opt/app/lib" );
}
use Application::Module;
[download]

What I really want is:

#!/usr/bin/perl
#
use strict;
use warnings;

BEGIN {
    local @INC = ( "/opt/app/lib" );
    use Application::Module;
}
[download]

I can add the 'eval' to make it work but I don't understand why it is necessary which bothers me no end...

update: BEGIN and compile-time has an explanation that I think I understand (I finally found the right super search!!). I hadn't contemplated nested BEGIN blocks before. My thinking to date on "compile time" versus "run time" has obviously been too simplistic.

This made me curious about when various nested bits run, so I have begun to experiment with the likes of the following...

#!/usr/bin/perl
#
use strict;
use warnings;

BEGIN {
    print "here we are in our begin block\n";
    eval {
        print "here we are in our eval block\n";
        INIT {
            print "here we are in an init block in an eval\n";
        }
        BEGIN {
            print "here we are in a BEGIN block in an eval in a BEGIN 
+block\n";
        }
    };
    BEGIN {
        print "here we are in our nested begin block\n";
    }
}

CHECK {
    print "here we are in our check block\n";
}

INIT {
    print "here we are in our init block\n";
}
[download]

Which produces:

here we are in a BEGIN block in an eval in a BEGIN block
here we are in our nested begin block
here we are in our begin block
here we are in our eval block
here we are in our check block
here we are in an init block in an eval
here we are in our init block
[download]

Most curious!! No doubt, when I come around to the Perl way of thinking it will seem quite correct.

update2: dufus me! I used an eval block when I wanted an eval string. Using a string makes the order of execution more what I expected (i.e. "run time" (relatively speaking) execution of the evaluated string.

#!/usr/bin/perl
#
use strict;
use warnings;

BEGIN {
    print "here we are in our begin block\n";
    eval '
        print "here we are in our eval block\n";
        INIT {
            print "here we are in an init block in an eval\n";
        }
        BEGIN {
            print "here we are in a BEGIN block in an eval in a BEGIN 
+block\n";
        }
    ';
    BEGIN {
        print "here we are in our nested begin block\n";
    }
}

CHECK {
    print "here we are in our check block\n";
}

INIT {
    print "here we are in our init block\n";
}
[download]

Produces:

here we are in our nested begin block
here we are in our begin block
here we are in a BEGIN block in an eval in a BEGIN block
here we are in our eval block
here we are in our check block
here we are in an init block in an eval
here we are in our init block
[download]

Comment on Changing @INC before use'ing a module in a BEGIN block Select or Download Code

Replies are listed 'Best First'.
Re: Changing @INC before use'ing a module in a BEGIN block by ikegami (Patriarch) on Mar 27, 2009 at 09:57 UTC
My thinking to date on "compile time" versus "run time" has obviously been too simplistic. Or too complicated. The reality is most simple: `use` and `BEGIN` statements are executed as soon as they are compiled.	[reply] [d/l] [select]
Re: Changing @INC before use'ing a module in a BEGIN block by Anonymous Monk on Mar 27, 2009 at 06:37 UTC
perldoc lib `use lib "/opt/app/lib"; use Application::Module;` [download]	[reply] [d/l]
Re^2: Changing @INC before use'ing a module in a BEGIN block by ig (Vicar) on Mar 27, 2009 at 06:58 UTC
Sorry, I wasn't explicit about my objectives for modifying @INC: I want to exclude the usual directories from @INC when I load application modules (including customized versions of core modules) so that they can only be loaded from the application library or fail to load, and I want to leave @INC unmodified after including the application modules. What you suggest prepends the application library directory to @INC without removing all the other directories, so that a module might be loaded from the usual libraries if it were accidentally omitted from the application library, and it leaves @INC modified after the application module is included, so it is not what I am looking for.	[reply]
Re^3: Changing @INC before use'ing a module in a BEGIN block by Anonymous Monk on Mar 27, 2009 at 07:04 UTC
Package name space is global, it makes no sense to localize @INC	[reply]
Re^4: Changing @INC before use'ing a module in a BEGIN block by ig (Vicar) on Mar 27, 2009 at 07:13 UTC
Re^5: Changing @INC before use'ing a module in a BEGIN block by Anonymous Monk on Mar 27, 2009 at 07:22 UTC