|
shahzama has asked for the wisdom of the Perl Monks concerning the following question:
A source code is written using module imported in the code on the desktop. When this code is run on the desktop, the compiler imports the module in code and runs the code. Now this code is deployed on server, again it will be required to have all the modules used in the code available on the server too, right ? Otherwise code will not run.
What I am making sure is, that perl modules are requred at both the places where code is created and where code is deployed, right ? |
Re: Availability of PERL modules
by kyle (Abbot) on Mar 27, 2009 at 21:20 UTC
|
| [reply] |
Re: Availability of PERL modules
by Marshall (Canon) on Mar 27, 2009 at 22:36 UTC
|
How you deploy your Perl code has a lot to due with the sophistication of the users and also how much time you want to spend on the installation/deployment package. Most of my code gets deployed to Windows end-users. These guys have never heard the word "Perl" much less "make". For this case, I make a stand-alone .exe file for Windows with the ActiveState tools. This works pretty well. I can stuff an icon into the .exe file and it looks familiar to them, "click here". It is also possible to make executable files for Mac and Linux.If you are deploying onto a Unix system with a system admin, then the sophistication level is vastly different and some base Perl stuff will already be there to assist a Perl installation script. This is a chicken and egg thing! I mean how do you run the CPAN module without Perl to begin with? You can also have your own Perl environment independent of system default, i.e it is ok for you to run Perl 5.10 even if they have 5.8. But 5.x was there in the first place to get you started! Anyway for the unsophisticated user, I recommend deploying an .exe file. The programs that I've deployed in source code format have been to sophisticated users who don't mind installing or verifying a few modules are there. So I guess this is a "your mileage my vary" thing.
| [reply] |
Re: Availability of PERL modules
by tilly (Archbishop) on Mar 28, 2009 at 08:25 UTC
|
I'm going to guess from the way you described this that you're dealing with Windows. For that case I've had luck with putting Perl and the required modules on a file server somewhere, and then giving end users a .bat file which uses them. You can start that with the utility pl2bat and then edit it slightly to make it refer to the copy of Perl on the file server.
If done correctly pure Perl programs will work with no local installation at all. And you don't have to create a large executable for every utility.
It has been some years since I did this. At that time I was using ActiveState. What I would do to set things up was install Perl on my machine, copy the Perl directory to the file server, find perlcrt.dll and copy that to Perl's bin subdirectory, then create my .bat files and away I'd go. I could not tell you whether there is still that dll dependency, or whether there might be a new dependency. You will have to experiment to figure out what works. | [reply] |
|
|
| [reply]
[d/l] |
Re: Availability of PERL modules
by sundialsvc4 (Abbot) on Mar 27, 2009 at 23:26 UTC
|
To reiterate the previous post... yes, everywhere the code runs, “the library code must somehow be available,” but no, “there isn't Just One Way To Do It.” (This is Perl, after all...)
There are lots and lots of ways to deploy a Perl application. One of them is to create an “executable” which is completely self-contained. It basically contains all the necessary Perl code, and looks only “inward, to itself,” to find it.
Perl = TMTOWTDI!
| |
Re: Availability of PERL modules
by Ish (Acolyte) on Mar 28, 2009 at 01:06 UTC
|
Another option would be to deploy the modules you want as well as the code and use
use lib "/wherever/you/deployed/them/";
in your code. I find this works for my own modules, so no reason you couldn't do this. However you may hit problems if these modules are then dependant on other modules etc.
Hope that is of use. | [reply]
[d/l] |
|
|
