view release on metacpan or  search on metacpan

docs/BaseLib-example1  view on Meta::CPAN

   and scripts in alpha version will say,

     use lib '/usr/local/mail2sms/alpha/mail2sms/lib/perl';

   With BaseLib? All scripts in all versions just still need to say,

      use BaseLib qw(mail2sms lib/perl);

   and they all refer to their respective private Perl module paths.

   And when I'm ready to turn the pre-release version into production
   version, I might need to move/copy the application set to, for example:
   /vhost/www/hasant.com. The environment variables, the web server
   conf, and the scripts remain untouched. The use() statement above will
   switch referring to:

      /vhost/www/hasant.com/mail2sms/lib/perl


SH] in the b) case, you will need something like this
SH] in the beginning of your Perl script:
SH] 
SH]   use lib $ENV{PROJLIBDIR};
SH] 
SH] or (if your lib dir name is fixed):
SH] 
SH]   use lib "$ENV{PROJROOTDIR}/priv_modules";
SH] 
SH] and then you can use PROJROOTDIR as a base to search
SH] for other directories, without defining many other
SH] environment variables (PROJBINDIR, PROJLOGDIR, etc.)
SH] 
SH] if you need to include other directories under
SH] PROJLIBDIR -- like i usually do because i install
SH] other CPAN modules under PROJLIBDIR -- you can do
SH] something like this:
SH] 
SH]   use lib $ENV{PROJLIBDIR};
SH]   use Includer;
SH] 
SH] where Includer.pm is located under PROJLIBDIR and
SH] pulls other directories into the search path:
SH] 
SH]   # contente of Includer
SH]   use lib "$ENV{PROJLIBDIR}/lib/perl5/site_perl/5.005";
SH]   use lib "$ENV{PROJLIBDIR}/lib/perl5/site_perl/5.005/i386-linux";

This will be handled by BaseLib to include the standard hierarchy
like lib module does.

SH] 
SH] or, you can use colon-separated path (like Unix's
SH] PATH) to let you include several directories:
SH] 
SH]   BEGIN {
SH]     for(split/:/,$ENV{PROJLIBDIR}) { use lib $_; }
SH]   }
SH] 
SH] your scripts can also refuse to run if PROJLIBDIR
SH] is not defined or looks suspicious.
SH] 
SH]   BEGIN {
SH]     for($ENV{PROJLIBDIR}){
SH]       croak "PROJLIBDIR is not defined!" unless defined;
SH]       ($_)=/(.*)/; # untaint like crazy
SH]       use lib $_;
SH]   }

Well, that's too much for the script. Besides, you missed
one bracket :-)

SH] and lastly, you can check to prevent the same
SH] directory included more than once if you want (as
SH] lib.pm doesn't do this currently).
SH] 
SH] the last two/three pieces of code can be put in the
SH] Includer module. the part checking the definedness
SH] of PROJLIBDIR can also be put in Includer should we
SH] decide to install Includer in the standard search
SH] path. and then all that is needed in the projects'
SH] scripts is this single line:
SH] 
SH]   use Includer;
SH] 
SH] you can also, of course, change the name 'Includer'
SH] if you hate it. :-)
SH] 
SH] among the cons for using environment variables is
SH] security (esp. for setuid scripts which are to be
SH] run under other people's environment). but so far
SH] i've managed to not need setuid scripts in my
SH] projects.
SH] 
SH] this approach is not perfect either, i believe, but
SH] so far it works for me.

Yes, I can see that. We have different requirement
and situation :-)

SH] as to your last question, i can't give an answer.
SH] but, sure, i'd say: go for it. (oops, i gave one
SH] :-)

Thank you very much for the input, for the discussion,
and for the support. I really enjoy discussing this :-)


Regards,
san
--