<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>Hey JBL, <br> I've had good results disting a centralized perl server instance successfully using the docs in:<br><span> <a target="_blank" href="http://www.penguin-inc.com/BMRCCUG/download/Interop4.htm">http://www.penguin-inc.com/BMRCCUG/download/Interop4.htm</a></span><br><br>This requires some intermediate SDLC disting theory and install permissions on various servers in your farm.<br>The wins are: <br>1. centralized major/minor version control of the interpreter. Theoretically, since I've only installed the next higher Major version of the interpreter, thus testing 5.next with the existing module collection that we are currently running at 5.current.<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">2. centralized modules version-ing
control. So in order to dist out multiple versions of the same [modules, packages, libs] from CPAN or localKeyboards, you will likely need to NAME the version of each module you 'require' or 'use'<br>e.g. use Win32::Process-0.13;<br> use TPM::getPerlServerInfo-0.13;<br>versus <br> use Win32::Process-0.14;<br> use TPM::getPerlServerInfo-0.15;<br><br>The calling sequence will also need some changing, depending how you spawn the script:<br>e.g. from crontab or the shell: \\newPerlServer\pathto\Perl\bin\perl -w
\\localServer\path\to\local\src\perl\myTestProgram.pl<br>or \\newPerlServer\pathto\Perl586\bin\perl -w \\localServer\path\to\local\src\perl\myTestProgram.pl<br>or
\\newPerlServer\pathto\Perl511\bin\perl -w
\\localServer\path\to\local\src\perl\myTestProgram.pl<br>In a 'real' dev shop, you might dist and run everything from *nix and have afs,dfs,nfs in place so you could cron/schedule/autosys, symlink, log, etc.<br>e.g. using ksh to fire it up using SheBang notation from within: #!/pathtobin/ksh -- # -*- perl -*-<br>with the appropriate munging of the env var for this ksh user.<span style="font-weight: bold;"><br>hth, /jordan<br><br><br><br></span><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> J. Bobby Lopez <bobby.lopez@gmail.com><br><b><span style="font-weight: bold;">To:</span></b> Toronto Perl Mongers <tpm@to.pm.org><br><b><span style="font-weight: bold;">Sent:</span></b> Wed, March 10, 2010 3:42:04 PM<br><b><span style="font-weight: bold;">Subject:</span></b> [tpm]
Question on CPAN modules and eliminating multiple installs<br></font><br>Hi All,<br><br>I have several applications installed on multiple servers, and many of them are using many of the same modules (both CPAN modules and custom modules).<br><br>I'm looking at ways of reducing or eliminating this duplication of code across systems - or failing that, implementing a way for the applications to rsync a central modules repository over to the local system on a regular basis.<br>
<br>What I'm looking for is the ability to grab modules from a remote system which are currently not installed on the local system, and stuffing them away in some non-root directory (e.g: ~/perl/local_modules/CPAN/, ~/perl/local_modules/CUSTOM/). Basically only grabbing the modules I need for a given server, and not everything available on the remote central modules repository.<br>
<br>Before I get ahead of myself and start designing this from scratch for my own purposes, I'm curious if there are any modules or tools that TPM's are currently using to do the same thing.<br><br>I've looked at some modules like Mini CPAN, but they seem to be attempting to implement a CPAN mirror of some kind, whereas I'm trying to implement a local repository of modules which are already installed and ready for use.<br>
<br>Thanks,<br>Bobby<br>
</div></div>
</div><br>
<hr size=1>The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! <a href="http://downloads.yahoo.com/ca/internetexplorer/"><b>Get it Now for Free!</b></a></body></html>