Re^4: layout/configuration of deployed files

I agree that my approach burns the users who execute my scripts, should somebody on my team create a Symbol.pm... However, what (I think) my approach avoids is the case that:

somebody sets up PERL5LIB to point to our libs, as a matter of course while setting up their day-to-day working environment (because they intend to run our scripts pretty regularly), and then
runs something that's got nothing to do with our scripts, and gets burned because our (badly-named) libraries take precedence

My boilerplate approach only hurts invocations of my scripts; the PERL5LIB approach hurts invocations of all scripts. Potentially.

I do like the idea of using a team-specific namespace... That seems clean, and enables me to leverage PERL5LIB. Thanks!

Comment on Re^4: layout/configuration of deployed files

Replies are listed 'Best First'.
Re^5: layout/configuration of deployed files by Eliya (Vicar) on Mar 02, 2011 at 20:35 UTC
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)	[reply] [d/l] [select]
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]