http://qs321.pair.com?node_id=836347

aplonis has asked for the wisdom of the Perl Monks concerning the following question:

Prolog: Once a long time ago somebody asked my help in getting an obscure module (LabJack::Device) going. Can't remember what all all the issues were, but they were plural. Finally in desperation I zipped up my entire C:\Perl directory and uploaded it to them. They swapped theirs for mine, tried it out, then wrote back with profuse thanks that now it all just worked.

Flash forward to now: So now I've got this issue with not being able, yet, to access PPM repositories from behind a firewall. No luck either in auto-building a whole repository for installation behind the firewall. So I'm getting desperate, and this thought occurred...

Might I perhaps populate my module collection on one PC from offsite, (my personal Vista Ultimate box at home maybe)...and then just zip up the entire C:\Perl\site directory or maybe just the C:\Perl\site\lib directory and drop that in onto my several XP boxen at work? Or would that be just too outlandish? Admittedly, I'm grasping at straws here.

Replies are listed 'Best First'.
Re: Cloning perl/site/lib directory?
by almut (Canon) on Apr 22, 2010 at 22:22 UTC

    For pure-Perl modules this should work just fine.

    For XS modules it might also work, provided you have the same version of Perl (at least the same major version, threaded vs. non-threaded build, same C runtime lib), the same architecture (e.g. 32-bit vs, 64-bit), and any dependent (3rd-party) shared libraries that some of the XS modules might be linked against (think of Imager, for example) are available (in the same versions) on both machines. — The problem with the latter often lies in the details...

      Can I get away with just C:\Perl\site\lib do you think? Or do I need all of C:\Perl\site?

        An XS library can link to theoretically anything on your system which means stuff that is outside the c:\Perl directory. So no guarantees that we will have copied everything over.

        If you are behind a firewall, perhaps you should create a CPAN::Mini on a USB drive( I would say CD but I think the size would approach 1+ GB) at home and then bring that to work (or where ever you intend to be using it).

Re: Cloning perl/site/lib directory?
by CountZero (Bishop) on Apr 23, 2010 at 09:42 UTC
    Actually that is what I am doing the whole of the time.

    I have installed ActiveState Perl on my laptop and then copied over the whole of the Perl directory to a server-share (which under Windows is accessible as a "drive") so it can be seen by all on our internal network. And yes we are all running Windows XP, so binary compatibility is assured.

    However as the paths are different on my laptop and on the server-share, I had to use the reloc_perl.bat script which is supplied with ActiveState Perl. The only "snag" is that the new path must not be longer than the old paths or else there is not enough space in the files to replace the paths. Then you add the "new" path to the users' PATH environment variable and you're done.

    After the initial relocation and copying, I now daily update the perl/site directory with rsync from my laptop and so far had no errors in running Perl from other machines. It seems there are no hard-coded paths in the files in perl/site (famous last words!).

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

      Yup, that works fine. Thank you so much!

      So here's what I did... Of my several Perl-enabled PCs at work, one is a laptop. I brought that home to my apartment for updating. I first renamed C:\Perl to C:\Perl_5.8.8 and deleted the old %PATH% from the Win32 environment variables. Probably I'll just wipe it later, but until I do, it's safely preserved.

      Next I loaded in ActiveState Perl 5.10 accepting all defaults so that it built to path C:\Perl which the installer recreated.

      Next I searched all my work-related Perl scripts for $_ =~ m|\nuse\s| which gave me a list of every module used. This I boiled down into a do-nothing Perl script that only called said modules. Eye-balling this list I installed each in turn (if not part of base) from PPM repositories first...or from CPAN if lacking in those.

      Then as a test I ran my do-nothing script to make sure it would indeed load said modules without complaint. Then I renamed C:\Perl to C:\Perl_5.10 and adjusted the %PATH% to match. Then after rebooting I ran the do-nothing script again. It did nothing without complaint so all was well.

      That done I packed up the laptop, toted it back to work and uploaded both the C:\Perl_5.8.8 (just because) and C:\Perl_5.10 up to the corporate U: drive where all my other PCs can fetch them down from. Will be fetching rather than running from there, though. I have my reasons.

      I went to my newest PC where earlier this week I'd been stone-walled trying to install packages because of some recent network update. I started out clean by blowing away my previous install completely. Then I copied down U:\Perl_5.10 into C:\, added a %PATH% to the new C:\Perl_5.10\bin\perl.exe and tried a few scripts. Viola! Issue resolved. Hurray!

      The reason why I chose to be copying all of Perl and not just Perl\site to up to the U: drive, is because I intend to do complete installs into C:\ on my other PCs as well. Why not just leave U:\Perl_5.10\site in one place and let the other PCs work from that? Well, it's because our U: drive not in the building. It's not in the city or even the state. It's located more than a whole time zone away.

      I have found that reading from or writing to U:\foo\bar poses a wee hazard. A full 99.99% of the time it's totally fine. But a couple of times I've had whole reports clobbered on a save-gone-wrong across that distance. So now, in spite of my boss's insistence, I work up my reports on my desktop and save to U: only at the end of the day, fearing the 0.01%. I'm treating all my scripts and logs that way also.