How many times Perl developers have to scratch their heads when they find that there is a module dependency which is breaking their code. Worse, they do not have sufficient privileges to install the required modules on the system. And the worst – there is no immediate way to get the module installed and the application needs to be tested/deployed ASAP! Well, I faced a similar situation during my experience in deploying a website on a shared hosting account, where I was on the mercy of the Hosting Service Provider to decide which modules I’m going to use and which not. But this is hardly the way a programmer works, and more so for a Perl programmer! I came across a few wonderful workarounds (hacks!) to overcome the above.
Download the module from CPAN or elsewhere. Place it in any directory, where you have permissions. Preferably, create a directory called
lib
in the application directory and place your module there. Untar it, you will see a few files and folders – Makefile.pl (to install the module, we don’t need this) , Readme.txt (this either), Examples (not required), lib directory – this is the only thing we are concerned with. It contains the main module files. Go inside the lib directory, and copy all the folders (if any) and all .pm files and place them directly inside the lib directory you just created. Remove all other files and folders.
The next thing which you need to do is go to the Perl code where you want to use that module and write the following:
BEGIN { unshift @INC, "./lib"; }
use Module::Name;
And voila!! Your code works like a charm with all the functionalities of the module included.
How it works? - When you use a module in a program, like
use CGI::Ajax;
perl searches for it in a predefined library search path on the system. You can determine which directories are in the path by executing
perl -e 'print for @INC;'
Any module in order to be usable in the program needs to be in any of the directories above, which is where the modules get installed if installed via
cpan or ppm
command or using Makefile.pl.
But in the situation discussed, it is not the case, as we cannot install a module as it should be. Instead what we do is place the modules in a directory of our choice (lib) and then insert the path of that directory in the
@INC
so that later when the perl interpreter tries to do
use Module::Name;
it finds its path in
@INC
Why BEGIN { } ? -
use Module::Name
happens at compile time, when the interpreter reads the program while
unshift @INC, "./lib"
happens at run-time, after the compilation, i.e, attempt to load the module, even if the latter is placed above the former in the program. So in order to force the program to modify
@INC
before trying to use the module, we use
BEGIN { }
block. Any code which is written within
BEGIN { }
block is executed at compile-time as opposed to other code which is executed at run-time.
Note: Remember that many modules have further dependencies, i.e. modules which are required for the former to work. And if these dependencies are not on the system, the code won’t work. You need to perform the above operations for each of those dependencies as well. For example, if CGI::Ajax requires Class::Accessor to work, you need to
a) create the directory CGI and place Ajax.pm within it
b) create the directory Class and place Accessor.pm and the directory Accessor within it and
c) unshift/push the path of the directory which contains these 2 directories CGI and Class, into @INC.
I have used this method to use more than 30 odd modules and have faced no difficulty whatsoever. However it will not work if the module’s Makefile.pl does more than just copying the .pm files in the right place and do some other work such as using external C libraries etc.
Another method of extending
@INC
is setting the
PERL5LIB
environment variable on your system to include the path of the manually placed modules.
In Bourne Shell do something like-
PERL5LIB=/path/to/module/directory; export PERL5LIB
It is useful when you do no want to write the BEGIN blocks in all the files where you use the module. But only users who are setting the
PERL5LIB
environment variable can only use it and other users can’t.
So I decided to tinker with Prototype and Script.aculo.us , to see if any good carousel is available which I can use as an image slider. I had previously used YUI Carousel by Bill Scott of Yahoo! but did not want to use it because it was way too heavy and hence slow to load initially. So I decided to take a look into jCarousel by Sorgalla which is based on the excellent jQuery Javascript framework. Both jQuery and jCarousel are very lightweight, feature packed, customisable, and contain almost all, if not all, the features of prototype and scriptaculous.
