I have been writing Perl scripts for my work and the machine that I have been given to work on makes installing Perl modules difficult:
We cannot have gcc on my machine for security reasons, so I cannot use CPAN to install modules, for most modules.
I do not have access to the root account.
Usually, when I want to install a module, I put in a request and I have to wait a day or two before it gets installed. I know that nobody would have a problem with me installing them myself, so to save everyone's time and my sanity I would like to install them myself. It's just an issue of how to best do that. I have talked to various people and they said to use an RPM to install them (to get around not having gcc). However, when trying to install modules from RPMs, it does not handle the dependencies so I would manually need to handle the dependencies, which could take a while.
How can I best install Perl modules with these limitations?
On a similar machine with a similarly built Perl, install the module(s) using
mkdir ~/foo
cpan
o conf makepl_arg 'PREFIX=~/foo LIB=~/foo/lib/perl5'
o conf mbuildpl_arg '--prefix ~/foo --lib ~/foo/lib/perl5'
install Some::Module
As long as you don't do o conf commit, the configuration change will be temporary, so don't do that.
Copy ~/foo over, and set env var PERL5LIB to include the LIB directory. You can merge a newer ~/foo into an older one to add new modules.
This won't install any non-Perl libraries on which the modules depend.
See also How do I keep my own module/library directory? in section 8 of the Perl FAQ.
When you build modules, tell Perl where to install the modules.
For Makefile.PL-based distributions, use the INSTALL_BASE option when generating Makefiles:
perl Makefile.PL INSTALL_BASE=/mydir/perl
For Build.PL-based distributions, use the --install_base option:
perl Build.PL --install_base /mydir/perl
INSTALL_BASE tells these tools to put your modules into /mydir/perl/lib/perl5. See How do I add a directory to my include path (#INC) at runtime? for details on how to run your newly installed modules.
There is one caveat with INSTALL_BASE, though, since it acts differently from the PREFIX and LIB settings that older versions of ExtUtils::MakeMaker advocated. INSTALL_BASE does not support installing modules for multiple versions of Perl or different architectures under the same directory. You should consider whether you really want that and, if you do, use the older PREFIX and LIB settings. See the ExtUtils::Makemaker documentation for more details.
Related
I'm taking a look into Perl as a total beginner. I want to try some CPAN modules.
When I run an install command on my Osx console, CPAN asks for a configuration with the following statement :
To install modules, you need to configure a local Perl library
directory or escalate your privileges. CPAN can help you by
bootstrapping the local::lib module or by configuring itself to use
'sudo' (if available). You may also resolve this problem manually if
you need to customize your setup.
What approach do you want? (Choose 'local::lib', 'sudo' or 'manual')
What is the difference between local::lib and sudo options ?
If I understand it well, it installs some modules locally on my computer. But I don't see any difference between the two config above.
If you use sudo, CPAN will use root to install the libraries in a central location where all users on the machine can access the files without any special configuration. If you use 'local::lib', it will create a library in your home directory and install the modules such that only perl programs that have been configured to look for modules in your home directory will find the modules.
Perl uses the special variable #INC to search for module paths. So you can install modules anywhere as long as you set #INC properly before you use them. This article explains the basics.
http://www.symkat.com/find-a-perl-modules-path
You can do all kinds of fun stuff with #INC; one of my favorite hacks it to put a function pointer in there and use custom perl code to lookup modules.
Good question. When you use local::lib, you can install Modules via CPAN User specific in an given directory. Assume you choose sudo as approach, you install Modules global.
Its like installing Node.js via npm. When you install a module with npm install -g <Modul>, its global installed and you can use it everywhere. But withouth that -g flag, its just available inside your current directory.
Its about the same here, except that you choose the default way of installing CPAN Modules.
So far I have been using the system perl (on Ubuntu 10.10) and I was using local::lib to install CPAN modules in my private directory ~/perl5
As I am trying to use perlbrew it seems that they don't know about each other. I installed perl-5.12.3 using perlbrew but when I switch to it using perlbrew use perl-5.12.3 I still see the PERL5LIB and PERL_MM_OPT set by local::lib.
That's not good:
$ cpan XML::Simple
/home/gabor/perl5/perlbrew/perls/perl-5.12.3/bin/perl: symbol lookup error: /home/gabor/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/auto/Cwd/Cwd.so: undefined symbol: Perl_Gthr_key_ptr
while
$ which cpan
/home/gabor/perl5/perlbrew/perls/perl-5.12.3/bin/cpan
so it is using the right version of the cpan client but dues to the PERL5LIB environment variable it picks up the modules from the wrong place.
Does perlbrew have some compability mode or do I need to turn off PERL5LIB and PERL_MM_OPT manually?
Since I started using perlbrew I stopped using local::lib for the shell use, because now that I have my own perl that i have write permissions to everything, just installing to site_perl is much more straightforward, and that allows me to have different versions of modules for each perl.
I still use local::lib (or more specifically, cpanm's -l or -L options that automatically sets up local::lib directory) to keep application specific dependencies inside an application directory.
local::lib was not designed to work with multiple versions of Perl installed at the same time. Pure-Perl modules aren't usually a problem, but XS modules aren't compatible across major releases.
You can continue to use local::lib for pure-Perl modules (so you don't have to install them for every version of Perl you have brewed up, but XS modules should be installed into the perlbrew-created directories. You don't need to clear PERL5LIB (and you shouldn't, as XS modules might have pure-Perl dependencies that are installed there), but you will need to clear PERL_MB_OPT and PERL_MM_OPT when installing XS modules to keep them from installing into the local::lib directory.
If you need to continue using local::lib for XS modules for the system Perl, then I suggest creating a second local::lib environment for that (perhaps in ~/perl5sys). It might be easier to use perlbrew to install a copy of the same version of Perl as the system Perl, and then use that instead of the system Perl.
You can clean out the XS modules in your existing local::lib by removing the /home/gabor/perl5/lib/perl5/x86_64-linux-gnu-thread-multi directory.
It is possible, but not comfortable. If this is a single-user setup, you might be better off not using local::lib and just letting perlbrew manage the modules for you. Also if it's a multi-user setup on a homogenous network, where everyone has the same machine and OS, then you can just set PERLBREW_ROOT to e.g. /net/share/perlbrew and then your installed perls (and their modules) can be shared. As noted in the other answers, this will be a problem if you try to mix machines (and possibly also problematic if you have different operating systems).
On a very diverse network, we prefer to keep everything separate. You can simply setup your local::lib to be a function of your current perl and your current platform, e.g.
distro=lsb_release -d|cut -f2|tr ' ' '-'
arch=`uname -m`
platform="$distro-$arch"
export PERLBREW_ROOT=/net/share/perlbrew/$platform
# You will have to first do 'perlbrew init' (just once for all users)
# In this case you don't need (and shouldn't have) a ~/.perlbrew
source $PERLBREW_ROOT/etc/bashrc
perl5base=/net/share/perl
# When $PERLBREW_PERL is not defined, local::lib puts modules in $perl5base/$platform
perl5=$perl5base/$platform/$PERLBREW_PERL
# We also found that we needed to clean PERL5LIB in between
export PERL5LIB=`echo -n $PERL5LIB|sed "s|${perl5base}[^:]*||g"`
export PATH=`echo -n $PATH|sed "s|${perl5base}[^:]*||g"`
# Setup local lib, relative to the perl being used
lib=$perl5/lib/perl5
mkdir -p $lib
eval $(perl -I"$lib" -Mlocal::lib="$perl5")
This is not our exact script, in particular you would need to check that these directories all exist first. You need to run perlbrew init once per platform and you need to bootstrap local::lib each time as well.
I don't recommend this approach, but provide as an example of one way to make this work, which it does for our mixed network (even on Mac OS). Leaving local::lib out and just using perlbrew (ignoring the system perl), would be a cleaner approach.
perlbrew is quite happy to use local::lib and has been for some time -- there are even special options for it -- after running perlbrew install ..., you can create a new local-lib directory with perlbrew lib create ...
for example:
perlbrew install -j 9 --as 34.0 5.34.0
chmod -R a-w $HOME/perl5/perlbrew/perls/34.0
perlbrew lib create 34.0#std
perlbrew switch 34.0#std
This installs a new 5.34.0 build, locks down its modules so you can't change them, then creates a local-lib directory. This install can be used with perlbrew use 34.0#std -- you can create a new set of module installations by perlbrew use 34.0; perlbrew lib create 34.0#other_install, to use side-by-side with the existing one without having to build a new perl again.
As miyagawa said, it might not be necessary to use local::lib if you use the Perls installed by Perlbrew exclusively.
But if you still want to be able to switch back and forth between your brewed Perls and the system Perl, there is a script called Perlswitcher for this. It's not pretty but it works. All you need to do is download the script, you could save it as ~/perl5/userperls/bashrc and source it.
It provides two commands. perlswitch allows you to switch to a Perl that was installed by Perlbrew or to the system Perl. perlinfo tells you which Perl is currently being used. You can then use cpanm, which will install packages to your local lib when using the system Perl or directly into the site Perl when using a custom Perl.
After switching to a custom Perl using perlswitch, perlbrew list will also know which Perl is being used:
$ perlswitch perl-5.18.4
Setting new perl /var/www/perl5/perlbrew/perls/perl-5.18.4/bin/perl...
Using user perl (site_perl) instead of local::lib
$ perlbrew list
perl-5.16.3
* perl-5.18.4
perl-5.20.2
When I installed perl from the source the first nice surprise was that without doing something all module installed from now on were available to the new perl. Since I didn't find one module on cpan that comes with my OS I have to use for some scripts the onboard-perl. For one of these scripts I would like to install Text::Format or Text::Autoformat (didn't find the docu for that module on cpan). My question: how can I tell cpan to install the module this one time for the OS-distro-perl?
There isn't a special way to tell cpan to install modules in a new location for just the one invocation. That feature, however, is on my to do list, along with local::lib support. I truly understand your pain and want the same feature. I just need the time (or the patch) to make it work.
Until then, you have to enter the CPAN.pm shell and change the values for mbuild_arg and makefilepl_arg as noted in perlfaq8: How do I keep my own module directory?:
When you build modules, tell Perl where to install the modules.
For Makefile.PL-based distributions, use the INSTALL_BASE option when generating Makefiles:
perl Makefile.PL INSTALL_BASE=/mydir/perl
You can set this in your CPAN.pm configuration so modules automatically install in your private library directory when you use the CPAN.pm shell:
% cpan
cpan> o conf makepl_arg INSTALL_BASE=/mydir/perl
cpan> o conf commit
For Build.PL-based distributions, use the --install_base option:
perl Build.PL --install_base /mydir/perl
You can configure CPAN.pm to automatically use this option too:
% cpan
cpan> o conf mbuild_arg "--install_base /mydir/perl"
cpan> o conf commit
Each Perl installation has its own idea of where libraries should "live", which the CPAN module uses as a guide for where to perform its installations. You can see what these values are by executing perl -V, and look for the value of #INC (at the bottom). If you invoke CPAN with a different Perl (e.g. your system-installed Perl), you will automatically install modules into that Perl's preferred location:
/usr/bin/perl -MCPAN -e shell
or to simply install one module without having to invoke the CPAN shell explicitly:
/usr/bin/cpan <modulename>
There are also CPAN configuration options available where you can temporarily or permanently change the install location, but this should not be necessary in your case.
/path/to/system/perl -MCPAN -e shell
I'm assuming you want to simply install modules to a different location and then run them from that location -- your question wasn't too clear to me.
Read the perldoc fully on local::lib. It would be a major failure on my part to try to write that better. This is also the most recent and advanced way to achieve this task. If another solution doesn't reference this module, then my personal suggestion would be to avoid it like the plague.
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.
Here is my situation: I know almost nothing about Perl but it is the only language available on a porting machine. I only have permissions to write in my local work area and not the Perl install location. I need to use the Parallel::ForkManager Perl module from CPAN
How do I use this Parallel::ForkManager without doing a central install? Is there an environment variable that I can set so it is located?
Thanks
JD
From perlfaq8: How do I keep my own module/library directory?:
When you build modules, tell Perl where to install the modules.
For C-based distributions, use the INSTALL_BASE option
when generating Makefiles:
perl Makefile.PL INSTALL_BASE=/mydir/perl
You can set this in your CPAN.pm configuration so modules automatically install
in your private library directory when you use the CPAN.pm shell:
% cpan
cpan> o conf makepl_arg INSTALL_BASE=/mydir/perl
cpan> o conf commit
For C-based distributions, use the --install_base option:
perl Build.PL --install_base /mydir/perl
You can configure CPAN.pm to automatically use this option too:
% cpan
cpan> o conf mbuild_arg --install_base /mydir/perl
cpan> o conf commit
INSTALL_BASE tells these tools to put your modules into
F. See L for details on how to run your newly
installed moudles.
There is one caveat with INSTALL_BASE, though, since it acts
differently than the PREFIX and LIB settings that older versions of
ExtUtils::MakeMaker advocated. INSTALL_BASE does not support
installing modules for multiple versions of Perl or different
architectures under the same directory. You should consider if you
really want that , and if you do, use the older PREFIX and LIB
settings. See the ExtUtils::Makemaker documentation for more details.
Download package form CPAN to a folder:
wget http://search.cpan.org/CPAN/authors/id/S/SZ/SZABGAB/Parallel-ForkManager-1.06.tar.gz
gunzip Parallel-ForkManager-1.06.tar.gz
tar -xvf Parallel-ForkManager-1.06.tar
before this create a folder in home to store your local modules, now go into downloaded folder and run follwing cmmands:
perl Makefile.PL PREFIX=/home/username/myModules
make
make test
make install
get the path to ForkManager from the installed folder,/home/username/myModules
and locate Parallel folder and get the full path to this.
Now in your perl file put these at the beggining
use lib '/home/username/myModules/bin.../Parallel';
use parallel::ForkManager;
--That should do it.
Check out this post from Mark Dominus
Excerpt:
Set PREFIX=X when building the Makefile
Set INSTALLDIRS=vendor and VENDORPREFIX=X when building the Makefile
Or maybe instead of VENDORPREFIX you need to set INSTALLVENDORLIB or something
Or maybe instead of setting them while building the Makefile you need to set them while running the make install target
Set LIB=X/lib when building the Makefile
Use PAR
Use local::lib
Mark also gives another solution in his blog which takes a bit more space to desribe but boils down to running make and make test but not make install and then using the stuff in blib/.
There's the PERL5LIB environment variable, and -I on the command line when it comes to using the module. There are mechanisms for telling CPAN and CPANPLUS.
There is information in question 5 of the CPAN manual (perldoc CPAN, or look at CPAN itself).
use lib 'directory';
use Parallel::ForkManager;
You can use the -I (capital i) command-line switch followed by the directory where you'll place the module; or try the "use lib" directive followed by the directory.
Yes Even You Can Use CPAN
perl Makefile.PL LIB=/my/perl_modules/lib/
make
make install
PERL5LIB=$PERL5LIB:/my/perl_modules/lib/
perl myperlcode.pl
use cpanm -l $DIR_NAME option.
perlbrew lets you use a local perl and installs it's packages to a local directory.
\curl -L https://install.perlbrew.pl | bash
perlbrew init # put this in .bash_profile etc
perlbrew install 5.27.11
perlbrew switch 5.27.11
See also https://opensource.com/article/18/7/perlbrew.
Consider using cpanminus, a suggested on this other thread