[Chicago-talk] Dynamic @INC builder?

[Don Drake]

My current project has a lot homemade perl modules and scripts that use
these modules.

I ran into the same problem with a development server, multiple developers
and a production server -- all with different paths to the location of our
scripts and modules.

First, everything is stored under a single "root" directory, e.g.
"/home/drake/falconperl" for dev, and "/data0/falcon" for prod.
Furthermore, all perl libraries are located in /lib under the "root"
(/data0/falcon/lib).

The way I have it setup is with a single environment variable (FALCON_HOME)
which is set in the users profile.

No module is required, only requirement is that the environment variable is
set.

I then use the following at the top of every script:
 use lib "$ENV{FALCON_HOME}/lib";
 ...
 use PCS::Nortel;

If the environment variable isn't set (or set incorrectly), nothing works.

It's not as dynamic as FindBin::libs, but that's OK.  Having a script "hunt
down" libraries can be viewed as helpful or hurtful depending on the library
it found, e.g. my home directory contains many old versions of installed
perl modules I don't want it looking there!.

Being explicit with a environment variable ensures a more predictable
outcome.

-Don

>
> This comes up when modules are installed in a local
> location (~/modules, for example) in one location on a
> development environment, but in a completely different
> location on a production environment.
>
> Say, for example, I have my own development modules at
> "/Users/jim/Documents/Perl", but when I deploy live
> they end up at "/home/thomason/perl/". Most annoying.
>
> Now, this is fixed by tacking on double use libs.
>
> use lib "/Users/jim/Documents/Perl/";
> use lib "/home/thomason/";
>
> But that's annoying. It gets worse when you factor in
> that I have a few scripts I like to deploy on several
> servers, requiring multiple lib calls.
>
> use lib "/Users/jim/Documents/Perl";
> use lib "/home/thomason/";
> use lib "/home/lm/";
> use lib "/home/tmr/";
>
> etc. Major nuisance. And, obviously, if I want to
> deploy on another machine, I need to go tack on
> another use lib. I know I could just use some tricks
> with symbolic links or ~ or whatever, but that ties me
> down to specific directory structures, and I don't
> care for that.
>