[tpm] Question on CPAN modules and eliminating multiple installs
J. Bobby Lopez
jbl at jbldata.com
Thu Mar 11 10:44:49 PST 2010
Thanks for the responses, much appreciated. I'll take a look at both and
see if either fits with what I'm looking for.
On Wed, Mar 10, 2010 at 5:19 PM, J Z Tam <jztam at yahoo.com> wrote:
> Hey JBL,
> I've had good results disting a centralized perl server instance
> successfully using the docs in:
> This requires some intermediate SDLC disting theory and install permissions
> on various servers in your farm.
> The wins are:
> 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.
> 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'
> e.g. use Win32::Process-0.13;
> use TPM::getPerlServerInfo-0.13;
> use Win32::Process-0.14;
> use TPM::getPerlServerInfo-0.15;
> The calling sequence will also need some changing, depending how you spawn
> the script:
> e.g. from crontab or the shell:
> \\newPerlServer\pathto\Perl\bin\perl -w
> \\newPerlServer\pathto\Perl586\bin\perl -w
> \\newPerlServer\pathto\Perl511\bin\perl -w
> 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.
> e.g. using ksh to fire it up using SheBang notation from within:
> #!/pathtobin/ksh -- # -*- perl -*-
> with the appropriate munging of the env var for this ksh user.
> hth, /jordan
> *From:* J. Bobby Lopez <bobby.lopez at gmail.com>
> *To:* Toronto Perl Mongers <tpm at to.pm.org>
> *Sent:* Wed, March 10, 2010 3:42:04 PM
> *Subject:* [tpm] Question on CPAN modules and eliminating multiple
> Hi All,
> 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).
> 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
> 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.
> 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.
> 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.
> The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo!
> *Get it Now for Free!* <http://downloads.yahoo.com/ca/internetexplorer/>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the toronto-pm