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

Fellow monks,

I'm slowly but surely spreading Perl at work - people see that I solve problems quickly using it, and ask to get it too. Others have to use programs I write so they install it. But I'm getting tired of installing Perl on all my co-worker's computers. I want to make a centralized installation in some common file system - this will also give me the benefit of installing all the modules from CPAN I use in one place. Two problems make my life harder:

  1. No unix - all the machines are Win 2K, the network is also Windows based. But we *do* have shared drives on the network.
  2. No internet connection - yep that's right, don't ask why. Our intranet is not connected to the outer world.

So, my plan of attack is as follows:

First I install the latest ActivePerl on a central drive that's accessible by everyone, say mapped to "S:". Then, I get minicpan from the internet, burn it on a CD and use it do install CPAN modules in my Perl installation space.

Since it's Windows and I want to use modules with C integration, I'll have to install nmake and the command line compiler of MS Visual 6 to compile stuff.

So, using these tools I'll install all the modules I need in S: and add perl to people's PATHs, and also to their %INCs.

The users' machines will load the perl executable from S: with all its modules and run it in memory so no performance problems bar some startup delay.

For laptops and PCs unconnected from the intranet, I'll use PAR to package stuff and run it stand-alone.

Anyone done anything similar ? Impressions ? Perl is a great tool and people recognize it - making it easy to deploy and use on "non friendly" networks will make it even more popular.

  • Comment on Deploying Perl centrally in a Windows-based intranet

Replies are listed 'Best First'.
Re: Deploying Perl centrally in a Windows-based intranet
by Corion (Patriarch) on Jun 03, 2005 at 07:15 UTC

    I basically have this setup, and it works well. perl lives in a directory on s:. My minicpan lives on \\aliens\cpan\minicpan with CPAN.pm configured to use file://aliens/cpan/minicpan/ as the base directory (and thanks to the LWP magic, this works).

    One difference I have is that I have no C compiler installed in the network, and I doubt that MSVC7 can be easily installed on a network share (or rather, I haven't investigated what is necessary for that). I solve that problem by installing the modules into Perl on one central machine, as I am the only Perl developer that mucks with XS modules anyway.

      Thanks for the rapid reply !

      I think you misunderstood my meaning about modules / C compiler - probably I phrased it badly.

      My users don't install their own modules. I install modules for people to use - so they know nothing about minicpan / cpan - they know that their scripts work. If I send a script to Bob and this script uses the Win32::SerialPort module, this module must be installed where Perl itself is.

      To install this module, a C compiler is required - only I use the compiler, once per module, to install it. CPAN.pm uses the compiler because the compilation is part of the module's Make process.

Re: Deploying Perl centrally in a Windows-based intranet
by inman (Curate) on Jun 03, 2005 at 08:37 UTC
    If you are using ActiveState Perl then you may as well download and install the ppm packages when they are available and use self-compiled modules from CPAN only when necessary. It will save you a lot of compiling related woes and get your project going faster. It will also be easier to support power users who have decided to have their own Perl installs.

    Take a look at the ActiveState site and search the mailing lists for perl network installation for various discussion about a network install. By the looks of things, the latest versions of AS Perl have a much cleaner install than earlier ones.

    You will also want to add a file association for .pl files using the assoc command.

      Thanks for the advice - I'm aware of AS's ppm - it *is* easy to use. But unfortunately, the amount of modules supported as ppms is minuscule in comparison with the vastness of CPAN.
Re: Deploying Perl centrally in a Windows-based intranet
by tilly (Archbishop) on Jun 04, 2005 at 03:08 UTC
    When you install Perl, it will edit %INC so you don't need to do that for people. It used to be, and likely still is, that when you install it that a couple of important dlls are put in your system folder. Look for PerlCRT.dll (not sure if there is another, and this may have changed in recent releases - I haven't seriously used Windows for years). Copy those to the bin directory on the shared drive.

    Now all that you need to do is edit the PATH, and you're done. In fact you should be able to just run pl2bat on your Perl scripts, and edit the result to call Perl explicitly in the right location.

    Good luck!

Re:Deploying Perl centrally in a Windows-based intranet
by PerlingTheUK (Hermit) on Jun 03, 2005 at 09:21 UTC
    I used local installations for all of us, doing an overnight sync to my machine for the lib and site\lib directory. However this was just for users, as I was the only person actively developing.
    We have since long ago however decided this is not a good solution and bought in PDK and I now use PerlApp. I would always prefer either of these options to a centralized Mapped network directory which is quite slow - at least in our network.

    Cheers,
    PerlingTheUK