[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:
>  http://www.penguin-inc.com/BMRCCUG/download/Interop4.htm
>
> 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;
> versus
>        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
> \\localServer\path\to\local\src\perl\myTestProgram.pl
> or
> \\newPerlServer\pathto\Perl586\bin\perl -w
> \\localServer\path\to\local\src\perl\myTestProgram.pl
> or
> \\newPerlServer\pathto\Perl511\bin\perl -w
> \\localServer\path\to\local\src\perl\myTestProgram.pl
> 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
> installs
>
> 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
> basis.
>
> 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.
>
> Thanks,
> Bobby
>
> ------------------------------
> 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...
URL: <http://mail.pm.org/pipermail/toronto-pm/attachments/20100311/72e98e6b/attachment-0001.html>


More information about the toronto-pm mailing list