I am creating a custom module to be placed in the directory /usr/local/cpanel/Cpanel. My perl module requires SOAP::Lite. Since the scripts placed in the directory /usr/local/cpanel/Cpanel are run under cpanel's internal perl version 5.6.2, does on install the SOAP::Lite module?
Trying to build the module with cpanel's build tool fails as another perl module is require to build the source module for soap::lite from cpan.
Perl modules are usually installed using the cpan program that comes with Perl. This checks all the dependencies for you and installs everything you need. This is what you should do.
If you don't have the ability to access and run this program, then you may not have permission to install modules at all. Possibly you could get whoever is running your system to do it for you (also ask them to upgrade your nearly 9 year old version of Perl while they are at it!).
Beyond that, there are not many options. You could try building the required modules on another, similar system and copying over--if you enjoy pain.
Related
I have a couple of perl modules installed in the $HOME of my web server. The web server used to run perl 5.8.8 so they were installed under $HOME/perl/lib/perl5/5.8.8/...
During a server migration, the web hosting company changed perl to 5.10.1 but I did not know about this until my scripts started failing. I managed to do a quick dirty fix by copying the 5.8.8 tree to 5.10.1 and it seems to work OK now, but I want to avoid my scripts failing like this in future.
What is the best way of allowing my scripts to use the locally stored modules under the 5.8.8 folder even if the perl version gets upgraded again?
I can add a check for the expected perl version in my scripts and email myself if it changes, but it's too late by then as the script may have failed several times before I can fix the problem. Ideally I want to prevent the scripts failing at all.
Depending on the amount of flexibility you have when configuring your environment you may want to use Perlbrew.
to maintain an independent Perl installation at a specific version. This can avoid nasty surprises when the system-wide Perl installation changes.
The thing you really should do is ensure that your needed modules are installed in the new installation. Especially for XS (C-level) modules there is no guarantee that they will run on a new version of Perl without recompiling since the core may have changed.
You should make a Makefile.PL or Build.PL which declares the dependencies of your scripts and you company should make it a policy to execute those scripts on server migration.
Finally, yes you can check $^V which is the running Perl. And if you do it inside a BEGIN block it will be executed during startup. In fact you can use local directories for your (pure perl) modules and then point to them using the lib module.
Why did you move the files at all? Just keep add to PERL5LIB instead.
PERL5LIB=$HOME/perl/lib/perl5/5.10.1:$HOME/perl/lib/perl5/5.8.8
I strongly recommend that you simply use perlbrew to install a build of Perl in your home directory instead of being at your host's mercy.
I have an application that I deploy on both Linux (Red Hat) and Unix (Solaris). My application installs itself using the built in Perl, and from then creates its own local Perl (new user).
I would like to know what is the best way to deploy Curses::UI? Currently I install other modules by just copying them to my local perl lib folder, but these are pure Perl modules that don't depend on C libraries (.so shared objects, XS, etc.).
Also will I have to compile libncurses for each platform beforehand?
NOTE: The computer doesnt have network connectivity, hence I cant use the CPAN module.
You should use a CPAN client (CPAN.pm, CPANPLUS) to deploy modules such as Curses::UI from CPAN. Usually you need development libs to compile XS modules. For Curses::UI the Ubuntu package is called libncurses-dev. Other Linux distributions probably have an ncurses devel package under the same or similar name.
You said you have a local Perl lib. A very good way to have a local lib is the module of the same name - local::lib. Its documentation will tell you how to easily install modules into your local::lib using a CPAN client.
For the CPAN modules that need to be built, try looking at carton. It has a bundle command that will bundle all your cpan modules together so they can be installed/built on the target machines without any network involved.
As for libcurses, I'd probably lean toward having a custom installer to build it on the target machine if it's not already installed. That or make your software refuse to be installed unless that library is found. Unfortunately I don't know of a good way to build dependent C libraries locally other than doing a custom build script.
I'm writing a Perl script that does date operations that need to take holidays into account, so I think I need either Date::Manip or Date::Calc. The server I'm going to put this script on is behind a firewall and therefore CPAN can't connect to the internet. Generally I can install Perl modules by just putting the .pm files in the Perl lib folder, but these two modules both have a C++ component or depend on a non-core module (YALM::Syck for Date::Manip) with a C++ component.
The server I'm deploying to also doesn't have GCC, so copying the installation package and building it there didn't work since it couldn't compile the C++. I tried building the packages on my home Linux PC and then copying them to the server, but got an error saying the module file was incorrect. The server is an IBM AIX box, so the module I compiled for my home pc is probably incompatible.
Is there any way I can get Date::Manip or Date::Calc working on this server? Are there any pure Perl (including dependencies) modules I could use instead?
All the favourites are not pure-perl.
http://deps.cpantesters.org/?pureperl=on;module=DateTime
http://deps.cpantesters.org/?pureperl=on;module=Date%3A%3AManip
http://deps.cpantesters.org/?pureperl=on;module=Date%3A%3ACalc
Set up a development box and mirror the production server. Install the compiler in the development environment. Build the modules and package them for deployment on production (AIX has packages, right‽).
You seriously need a proper toolchain for your server, including a compiler. It's fine to build the CPAN module on another machine and copy the installed files across, but obviously the build environment has to have the same architecture, same OS, and same perl version as the operational server.
I downloaded the 5.12.3 installer to upgrade my 5.12.1 installation. After installing 5.12.3, my previously installed cpan modules are gone. Is this expected behavior? Should I be backing up my library before upgrading to prevent this?
I would claim that this should not be expected behavior.
The site directories are not part of the standard distribution and should not be touched by the distribution. Heck, it's even why the site directories even exist. Otherwise, why not simply download all of the modules to the same directory? Why make a distinction between the standard Perl modules and the modules you download from CPAN?
I too found this out the hard way when my personal modules -- modules that are not part of CPAN -- were blown away by my upgrade of Strawberry Perl. ActivePerl does it right -- not only not touching the site directory, but also adds in the Perl version to the standard module directory and the site directory.
It is expected behavior. Next time you can use "autobundle" feature of CPAN client, it will create list/bundle of modules to reinstall using CPAN client in new version.
I want to send emails using gmail's smtp servers and perl. I am trying to install Email::Send::Gmail, but it is not clear to me what are the steps to install it. It seems that it depends on other modules that I do not have installed.
This is partially dependent on which distribution of Perl you're using.
ActivePerl includes a utility called PPM (Perl Package Manager) for installing modules. It handles dependency resolution automatically. PPM is particularly nice for installing XS modules on Windows where a compiler isn't typically available. The downside to PPM is that it some CPAN modules aren't available (probably because they fail ActiveState's automated build process). You can run PPM from either the start menu or by typing ppm at a command prompt.
A more general option is to use the interactive CPAN shell. Note that you must have a compiler to install XS modules using this method. You can access the cpan shell by typing cpan at a command prompt.
The brute-force approach of last resort is to download tarballs from CPAN and manually install them one at a time. When an install aborts due to unsatisfied dependencies download and install them then go back to the first module and try again.
Type:
cpan Email::Send::Gmail
… at the command prompt.
It's probably a good idea to set up local::lib first.
Or see the Perl Foundation Wiki on installing CPAN modules or the same but without root access.
Or see the CPAN guide to installing modules.
If you are using ActivePerl, try the PPM (Perl Package Manager) tool that comes with ActivePerl first. When you tell it to install a module, it should handle all of the dependencies for you.
Note the dependency tree for Email::Send::Gmail. Some of those modules require additional installation of third party software, most notably OpenSSL, which cpan won't do for you.
You can probably install it with:
perl -MCPAN -e shell
install Email-Send-Gmail
Hope it helps,
/Klaus
If you can, CPAN. (ha! It rhymes ... what a crime. Oops, did it again! When will this end... :p) It's essentially the way to install modules for your system. It automatically detects dependencies, downloads, installs, and tests them all for you, and backs out if ever a build or test fails. It's a fantastic and reliable way of installing modules. This works great if you're using essentially any Perl distribution besides ActiveState's distribution, including Strawberry Perl. Generally, this is done with
cpan Module::Name
or, in an interactive mode,
$ cpan
cpan > install Module::Name
If you're using ActiveState Perl, then you probably want to use ActiveState's PPM (Perl Package Manager). It's similar to CPAN, except everything comes prebuilt for ActiveState Perl. ActiveState has a document on how to use their Perl Package Manager on their website, including a graphical example.
If the easy options fail, you are not out of luck. There's some more complex, but manual methods you can do to still install the module.
Most modules that you can download will have within them a bit of metadata in a .yaml file; this will help you figure out whether or not you have all your dependencies. CPAN and PPM automatically resolve and install all your dependencies, but doing it manually will not, leaving that task up to you.
Assuming you have all your dependencies, and you need to install it manually, look for one of two files: Makefile.PL or Build.PL. If you have a Makefile.PL, cd to the directory you extraced the module within a command prompt, and type:
perl Makefile.PL
make
make test
make install
You will need a 'make' program on your system. If it's ActiveState Perl, you may need to install the module manually (see a paragraph or two down.)
If it happens to have a Build.PL, then you need to do a slightly different set of steps:
perl Build.PL
Build
Build test
Build install
(Of course, you may want to consider not installing if make/Build test fails, but that's up to you.)
As a final alternative, if your module has no xs files (ie, code that needs to be compiled on install), and all dependencies are met, you can simply move the files in the lib folder to your perl installation's site\lib folder. If you're interested in just using it for one project, you can add a PERL5LIB environmental variable, pointing to a new, custom library directory (eg, /my/project/lib) and then before running your tool, make sure the environment is set up.
As a followup, see PerlFaq8 - How do I install a module from CPAN.
Also, see PerlFaq8 - How do I keep my own module/library directory?.
Mixing installation methods is asking for heartache and headaches you don't need.
Don't use CPAN with Active Perl. Use PPM.*
PPM download sources can be found at Randy Kobes' site.
If you can't find a PPM of a module you need, you can build your own PPMs easily with Mr. Kobes make_ppm.
You can download a distribution and simply run make_ppm to build a PPM, but I prefer to do the a more "normal" build process:
perl Makefile.PL
make
make test
make_ppm
*If you install your files outside of c:/perl/site/* then it's OK to use CPAN. Just don't co-mingle CPAN shell modules with PPM modules.