Re^5: layout/configuration of deployed files

Don't require your users to set PERL5LIB themselves in order to run your scripts. Set it yourself (locally for the process), in a wrapper script, or some such. If they then still insist on pointing their PERL5LIB to your private libs in their day-to-day environment, it's their problem...

You could also write the wrapper such that it copies the contents of some other env variable (e.g. XX_ROOT) into PERL5LIB. This way, they could make their choice by setting XX_ROOT without affecting anthing else, while you can still take advantage of PERL5LIB, to avoid littering use lib all over the place.

#!/bin/sh
export PERL5LIB=$XX_ROOT
exec ...
[download]

P.S.: Perl's -I command line option could be used similarly:

#!/bin/sh
exec perl -I$XX_ROOT ...
[download]

(you can only specify one directory per -I option, though)

Comment on Re^5: layout/configuration of deployed files Select or Download Code

Replies are listed 'Best First'.
Re^6: layout/configuration of deployed files by klassa (Acolyte) on Mar 02, 2011 at 21:39 UTC
I'm trying to envision a way to do that that's less verbose than putting the boilerplate into each script to begin with. :-) For example, let's say each script has its own wrapper... That is, "script1" is really just a wrapper that sets up PERL5LIB and then invokes "script1.real". In that case, you've got 2x the number of scripts (one wrapper, one real) and each wrapper effectively has the boilerplate in it. Even with a virtualized wrapper (i.e. one that you symlink to, that decides what to exec on the basis of $0), you've got N scripts and N symlinks. Is this what you meant, or did I misunderstand?	[reply]
Re^7: layout/configuration of deployed files by Eliya (Vicar) on Mar 02, 2011 at 22:36 UTC
Personally, I'd prefer having one additional wrapper plus a bunch of symlinks — in particular as it helps keep the installation/usage specifics out of the scripts or modules. So, if you should have to deploy them in another environment with different needs, you would just have to adapt one wrapper (in case it's required at all in that environment). YMMV, though :)	[reply]