Bug #75098 for Catalyst-Runtime: Catalyst::ScriptRunner doesn't load "lib" directory to @INC anymore

Fri Feb 17 08:25:04 2012 gutsch [...] cabshare.de - Ticket created

Subject:

Catalyst::ScriptRunner doesn't load "lib" directory to @INC anymore

Trying to start "./script/<myapp>_server.pl" (even a freshly bootstrapped one), results in "Can't locate MyApp.pm in @INC". Solution is simple to run "perl -I lib ./script/<myapp>_server.pl" but it's quite inconvenient (at least to me) and beginners reading the manuel certainly won't be happy to see an error message on startup. Here's what I found: As the Changelog sais: "The Catalyst::Utils::home function is used to find if the application is a checkout in Catalyst::ScriptRunner". in sub "run" (lines 38-39) 5.90007 sais: if (my $home = Catalyst::Utils::home($appclass)) { lib->import(File::Spec->catdir($home, 'lib')); } whereas it's been like this in 5.90007 (w/o if-clause): lib->import(File::Spec->catdir($FindBin::Bin, '..', 'lib')); Catalyst::Utils::home seems to look at %INC returning undef for MyApp which results in lib->import(..) not beging called. Look like a loophole for me because Catalyst::Utils::home($appname) will not return anything unless lib->import(File::Spec->catdir($home, 'lib')) has been called (or -I lib was specified to the perl interpreter). So if this is desired behaviour, it should clearly go to the docs. But I certainly don't like it (having to rewrite lots of startup scripts) the way it is. The situation above applies to both my WinXP/64 (perl 5.12) and Linux/64 (perl 5.10) dev boxes.

Fri Mar 02 06:56:11 2012 johnw [...] cpan.org - Correspondence added

I have this problem too. It seems that this is because of the way that the "find_home_unloaded_in_checkout" method is determining the base directory. The algorithm seems to expect the location of the running program to have a lib or blib within it. In a standard (classic?) catalyst development directory structure, as made by catalyst.pl, this isn't the case. There may be a good reason for this being like this, so I am assuming it is there for a good reason. However, this doesn't seem to work for the default case for Catalyst development. I have attached a patch ( diff -e ) that augments this method. Once patched, it works for me. (sudo patch -e /usr/local/share/perl/5.12.4/Catalyst/Utils.pm patch.ed # until this is included/fixed in an alternate fashion) All this does is, after the package performs the "use the parent directory while lib or blib is present", it now additionally performs a "use the parent directory if this script is the last part of the path" Hope this helps, and doesn't cause different issues. On Fri Feb 17 08:25:04 2012, MGUTSCH wrote: Show quoted text

> Trying to start "./script/<myapp>_server.pl" (even a freshly > bootstrapped one), results in "Can't locate MyApp.pm in @INC". Solution > is simple to run "perl -I lib ./script/<myapp>_server.pl" but it's > quite inconvenient (at least to me) and beginners reading the manuel > certainly won't be happy to see an error message on startup. > > Here's what I found: > > As the Changelog sais: "The Catalyst::Utils::home function is used to > find if the application is a checkout in Catalyst::ScriptRunner". > > in sub "run" (lines 38-39) 5.90007 sais: > > if (my $home = Catalyst::Utils::home($appclass)) { > lib->import(File::Spec->catdir($home, 'lib')); > } > > whereas it's been like this in 5.90007 (w/o if-clause): > > lib->import(File::Spec->catdir($FindBin::Bin, '..', 'lib')); > > Catalyst::Utils::home seems to look at %INC returning undef for MyApp > which results in lib->import(..) not beging called. Look like a > loophole for me because Catalyst::Utils::home($appname) will not return > anything unless lib->import(File::Spec->catdir($home, 'lib')) has been > called (or -I lib was specified to the perl interpreter). > > So if this is desired behaviour, it should clearly go to the docs. But > I certainly don't like it (having to rewrite lots of startup scripts) > the way it is. > > The situation above applies to both my WinXP/64 (perl 5.12) and > Linux/64 (perl 5.10) dev boxes.

Subject:

patch.ed

Download patch.ed
application/octet-stream 93b

Message body not shown because it is not plain text.

Fri Mar 02 06:56:14 2012 The RT System itself - Status changed from 'new' to 'open'

Tue Mar 13 18:22:57 2012 bobtfish [...] bobtfish.net - Correspondence added

This is fixed in the latest release. Thanks for the bug report!

Tue Mar 13 18:22:59 2012 bobtfish [...] bobtfish.net - Status changed from 'open' to 'resolved'