[Catalyst] Catalyst 5.90010 server must be in CWD to run?

[Louis Erickson]

On Feb 21, 2012, at 5:24 AM, Eden Cardim wrote:

>>>>>> "Louis" == Louis Erickson <lerickson at rdwarf.net> writes:
> 
>    Louis> Looking at @INC, it's clear that Catalyst no longer adds
>    Louis> "$basename/../inc" to the path - I haven't dug into the code to
>    Louis> find where the change was.
> 
> You mean ../lib, right?

No, I mean ../lib relative to the script's main directory.  If I'm in / and run the script with a full path, I don't want or expect ../lib to be added to @INC.  I want and expect the script to find the paths relative to itself, as the structure of the app as it is often used are.

>    Louis> I know all the help and samples have people run
>    Louis> "script/myapp_server.pl", but I never do; I run it from the script
>    Louis> directory.
> 
> There's no problem with that at all (caveats given below), but do you have a
> specific reason for doing it that way?

Mostly habit, honestly.  Twenty years of my fingers running programs with ./whatever instead of from a directory up.  I can change that, especially if there's a good reason.

I'm more concerned about what this will do to fastcgi and my production web servers.

In the virtual host file for Apache, I currently have:

Alias / /path/to/app/script/myapp_fastcgi.pl

... and some other stuff to engage that as FastCGI instead of ordinary CGI.

Nowhere does it set a working directory.  What will it be?  /?  DocumentRoot?  The script directory?

So, to upgrade, I'll have to modify PERL5LIB to add the lib directory there, which it used to get right on it's own.  I'm sure that'll be a pleasant surprise to a lot of people.

> 
>    Louis> I'm also concerned that having to be in the right CWD
>    Louis> will allow loading of unexpected modules, rather than being based
>    Louis> on the app's location, as I'd expect.
> 
> This isn't much about the CWD, it's about setting the right @INC, which is a
> problem related to perl (and pretty much any programming language) as a
> whole. You can run the app from anywhere, as long as you tell it where to find
> the libs it needs. If you used the standard scaffolding script, that should be
> lib/ under your MyApp dir, plus the site_perl libs (which are hard-coded into
> @INC by the perl binary in most cases). If you're concerned about loading
> unexpected modules, sanitize @INC before you use() anything. Catalyst tries to
> make a few guesses as to what @INC should be, and the doc examples try to
> match those assumptions, but there's no way it can catch all the possible
> scenarios, so if for some reason you decide to do something different than
> what's doc'ed, you'll need to adjust the environment accordingly.

This is about CWD, at least my concern is.  Changing the CWD shouldn't affect the operation of the program.  To run a program, the operator shouldn't have to dig in and provide the library paths.  That's something the program should be able to know on it's own, either through configuration or inspection.  Perl has obvious tools to make that possible.

The site_perl is, indeed, set by Perl.  I have some other local stuff set in PERL5LIB.  I know how to work around this... I'm asking why that's suddenly needed.  This is a behavior change, and I'd like to know if there's a reason for it or if it can be fixed.

>    Louis> Is this a deliberate change?  Is there a reason for it?  Or is it
>    Louis> an unexpected change?
> 
>    Louis> So, I'd think this is deliberate.  It will also affect all the
>    Louis> scripts.  What is this going to do to myapp_fastcgi, when the
>    Louis> webserver doesn't set the WD as expected?
> 
> I'm not exactly sure about the specific motivation for that change, but
> script/myapp_fastcgi.pl is just a perl source like any other, adjust @INC
> before running it (via PERL5LIB, -I, etc.) and you'll be fine.

I'm aware of the plethora of ways it is possible to set @INC.  Converting from ./myapp_server.pl to perl -I../lib myapp_server.pl isn't something I'm looking forward to for development.

Having to reconfigure all the production instances of the webserver to set a proper working directory and/or PERL5LIB isn't either.  It's certainly an unexpected change.  In the past, the scripts have always found the proper lib directory on their own.  Why must I suddenly tell them explicitly or work more carefully so it just happens to line up?

Another person responded that "checkout" meant "checked out from source control", and yes, I'd guessed that.  Checked out instead of what? How does that change the environment?  Who is that affecting and how?  Do the scripts not run in MyApp/scripts there, or is the difference for the alternative?  Would that be after running 'make install', and then being in the path somewhere?  Wouldn't finding lib be even more critical in that case?  Adding a ../lib or even $basename/../lib wouldn't be appropriate there.

I haven't had time yet - and now that the work week has started, won't for a day or two - to dig into the function that changed and see what changed.  Without knowing why the change was made I'm not sure anything I could suggest would be useful.