Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Moving Perl from test to Dev

by Anonymous Monk
on Nov 20, 2003 at 15:53 UTC ( #308601=perlquestion: print w/replies, xml ) Need Help??
Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

What's the best way to migrade perl from dev to staging? It is too much work to install module by module. We have a lower rev in staging. Need to take the whole perl 5.8 and move it over. Any help would be much appreciated!! thanks you very much

Replies are listed 'Best First'.
Re: Moving Perl from test to Dev
by Abigail-II (Bishop) on Nov 20, 2003 at 15:58 UTC
    Package up your entire perl tree (tar will do fine) and copy that to your staging environment.

    Abigail

      That works great if your environments are on different systems. All you have to do is move your scripts over from one environment to the other and they should work immediately if perl is in the same location (such as "/usr/freeware/bin").

      But what if you have your staging environment on the same system as your test environment? It seems that there would be a few decisions to make. If separate copies of the same version of perl must be maintained for some reason (i.e., for backup or other portability issues), then installing perl in a default location such as "/usr/freeware/bin" may not be good.

      It seems that you would want to set up separate directories, one for test, one for dev, each containing an installation of Perl. For ease of switching between versions, you could either change the symbolic link "perl" to point to your desired version, or alter the #! line in every script when rolling them from dev into test. Neither of those seem to be great options.

      I'm not offering solutions, here, just points to consider. Perhaps someone else has gone through this and has a much more efficient solution.

        If your test environment and your development environment are on the same box, you have a problem. Either they use the same perl (not desirable, otherwise you can't upgrade/replace the perl in one place, while not touching the other), or you have them at different locations. But then your test environment is different from your development environment, and that's far from ideal as well.

        I strongly recommend against that. Otherwise, you might be able to get away with just reconfiguring/compiling/installing perl, and copying the locally installed modules. Or you might want to search for 'relocatable perl's. It seems to work on some OSses (OS/2 for instances), and some people (Redhat?) have success with configuring perl with a huge default @INC, and a binary edit of Perl. I don't think perl relocation is officially supported though.

        Abigail

      Add a step for ActivePerl on Windows systems. Run the reloc_perl script from the bin to "relocate perl" and see ActiveState and the script itself for docs.

      welchavw

      For sure you will run into problems in a Windows environment where various DLL-modules will need to be properly registered or else they may fail.

      CountZero

      "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

        The only adminny thingies I've ever done on a Windows machine are 1) setting an IP address and 2) asking someone to install Cygwin for me.

        You've given me another reason to keep it that way.

        Abigail

        Hmmm....I have never hit any problems in this regard. My understanding is that DLLs will never need to be "registered" unless they do OLE-ish kinds of things. My guess is that I have never needed to use any OLE-ish perl DLLs on Win32. I copy perl installations around to different Win32 hosts quite frequently and run reloc_perl and its been all smooth sailing. Are you just guessing that various modules will fail or can you cite examples? I would be interested to know what you have found necessary to avoid.

        ,welchavw

Re: Moving Perl from test to Dev
by adrianh (Chancellor) on Nov 20, 2003 at 16:10 UTC
Re: Moving Perl from test to Dev
by chromatic (Archbishop) on Nov 20, 2003 at 18:58 UTC

    Have you considered keeping everything (including external modules) in source control?

      I recommend against the external modules in source control. What are you checking in? If it's gzips, then that's no good. If it's the pm's, then you have a concurrency issue.

      Personally, I'd keep a checklist of steps to take, preferably in some script. That way, you can (re)build your environment on (nearly) any machine known to man. Kick the script off, then go home for the night. :-)

      Personally, I have a small "install" script that will go through source control and copy over things that have changed. It works for me ...

      ------
      We are the carpenters and bricklayers of the Information Age.

      The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

      ... strings and arrays will suffice. As they are easily available as native data types in any sane language, ... - blokhead, speaking on evolutionary algorithms

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

        Personally, I'd keep a checklist of steps to take, preferably in some script.

        Yep. That's what I do too. And the "script" is almost always called "Makefile". I love make. I use it everywhere. ;-)

        Abigail

        What concurrency issue?

        If you want to be sure that you have the same version of modules on the development box as on the production box, you need to keep local copies somehow. Setting up your own CPAN mirror would also work.

        You may not think you'd want this, but there several useful CPAN modules that have occasional backwards-incompatible changes. Hoping you won't run into that isn't nearly as effective as making sure it won't bite you.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://308601]
Approved by JSchmitz
Front-paged by JSchmitz
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2018-05-23 19:23 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?