Re: Deployment Qs

I'm acutally in a similar boat with a project that I'm working on. Here's some things that can help.

1) if you're using ye-olde "perl Makefile.pl" method of installing your system, or you *can* use this method; add options to your WriteMakeFile configuration that look like this:

INSTALLSITELIB => '/opt/bamf/lib',
INSTALLSCRIPT => '/opt/bamf/bin',
EXE_FILES => ['relative/path/to/pl1','relative/path/to/pl2]
[download]

The first line (I think) will override the default location for the installation of the pm's. The second spells out where the executable scripts go, the third lists the executables to be installed. The handy thing that this process also does is that it fixes the #!/perl/lives/here lines in those scripts to match the location of the perl that executed the Makefile.PL.

2) You could use CPAN to install / update each system to the latest version of the required modules at the time you run 'perl Makefile.pl'...this of course assumes that CPAN is configured on each of these systems.

3) If it's a rule that your application's layout has 'bin' and 'lib' as siblings of the same directory, you can use File::Spec to figure out where lib is at run time or within a BEGIN block.

use File::Spec;

my $lib_path = File::Spec->rel2abs($0);
$lib_path =~ s/\/bin\/[\w\d-]+\.pl/lib/;

push(@INC,$lib_path);
[download]

Another nice thing about using the Makefile.pl approach is that it will run your test suite before it performs an upgrade of your application. This way if some new feature doesn't work on machine X, you didn't trample an old (but working!) installation.

edit fixed typos.

/\/\averick

Comment on Re: Deployment Qs Select or Download Code

Replies are listed 'Best First'.
Re^2: Deployment Qs by ph713 (Pilgrim) on Oct 07, 2005 at 05:10 UTC
I went out and saw a really stupid cheesy movie with someone, and it got my mind off of this project (for the first time in a few weeks I think) long enough for some subconscious something to kick in. After getting home I was immediately aware that avoiding the make process was the mistake that led to this mess. It just took some time away from it for it to sink in after you mentioned it. My path is clear now, I need to: Make a simple /bin/sh script (lets call it Installer.sh) that will run on any remotely reasonable *nix system and detect the latest available perl from the finite list of possibly directory paths. Then it executes something akin to "`/some/where/perl Makefile.PL && make && make test && make INSTALLDIR=$1 install`" with the appropriate perl. This isn't hard to do by sticking to pure bourne shell constructs and simple tools like basic grep. Get a perl-style Makefile.PL built up for this project, and customize it so that it transforms #!/usr/bin/perl on the scripts to the perl that was used during the make, and so that it can be told what directory to install the software to, and transform some push(@INC,'...') line in all the scripts to point at a library directory located there, like what you described Profit! (or at least, keep my job :) ) Anyways, thanks, your mentioning of using the standard perl Makefile.PL stuff and those variables got me thinking straight(er).	[reply] [d/l]
Re^3: Deployment Qs by demerphq (Chancellor) on Oct 07, 2005 at 12:00 UTC
IIRC you wont need to do step 2. If you scripts are identified as such then the install process will do this for you. --- $world=~s/war/peace/g	[reply]
Re^2: Deployment Qs by ph713 (Pilgrim) on Oct 07, 2005 at 01:04 UTC
Unfortunately I'm not using perl Makefiles for this, at least not yet. I had to some degree pretty much dismissed the perl make system for this project, but I may need to go back and re-examine that decision. Ultimately, this project is not a perl script or a perl module - it's a complete software package that runs multiple daemons as root on the system and offers a few commandline tools for sysadmins as well (it's essentially the client side of a systems management/monitoring system of sorts, with some rather hardcore requirements in terms of scalability and precision). I was doing something very similar to your File::Spec method earlier on, and it may ultimately be what I have to do in production. However, I was doing it "manually" without File::Spec, which resulted in ~8 lines of code instead of your 2-3 (it's significant to me, because that block of code basically has to be copy+pasted into every script in this system, there's no real sane way to modularize it and eliminate the redundancy that I've found). Tack on the "find the best perl interpreter" problem, and you've got a decent little block of code which must be pasted into BEGIN{} at the top of every script. It looks like File::Spec 0.8 is when rel2abs() was introduced, and File::Spec 0.8 became part of the core in perl 5.5.x somewhere, so it should be cool for me to use it implicitly in the begin block like that. At least that shortens things up a bit	[reply]


"be consistent"
	PerlMonks