Is it possible?
If you download the source code, and read the README file. This will probably tell you you should do
perl Makefile.PL
make
make test
make install
or
perl Build.PL
./Build
./Build test
./Build install
If you download the source code, it will generally have a Makefile.PL. You run "perl Makefile.PL; make; make test; make install" and it will build and install for you.
Obviously if you're not using CPAN.pm, you're going to have to deal with dependencies yourself.
Also, if the reason you can't use CPAN.pm is that you don't have permission to install into /usr/lib/perl, you can force CPAN.pm to install locally, but I forget how.
If you are on a Linux box, a very large portion of the packages can usually be obtained using the built in package manager. For instance, on an Ubuntu system, if you want to install the PostgreSQL Perl module you'd simple do:
sudo apt-get install libpg-perl
You can see a list of the modules for Ubuntu here: http://packages.ubuntu.com/hardy/perl/
I find I can often guess at the names myself. Not sure if this helps at all, but for myself I often find this easier to use than CPAN as it does a lot better at resolving dependencies.
See here: How to install perl modules using CPAN without root
I have just set this up on a server without root access and CPAN does everything automatically.
But if you really wanna install a module without CPAN and you don't have root (assuming this since you don't wanna use CPAN), you can do it as follows
perl Makefile.PL PREFIX=$HOME
make
make install
You're gonna have to hunt down dependencies yourself so it's better to use CPAN.
If the problem is no root access, I would recommend looking at local::lib and also this webpage for CPAN.pm and non-root installation.
But to answer the question as asked, CPAN or CPANPLUS are helpful, but they aren't required. You can always do it the old-fashioned way as Leon says - though usually, it's easier not to.
If you are using Red Hat (Fedora, CentOS), you should use RPM for Perl dependencies wherever possible. Perl packages are almost always named perl-Module-Name, e.g. perl-DBI, perl-Spreadsheet-WriteExcel, etc.
On Ubuntu the naming scheme is libmodule-name-perl.
If the .pm file is pure Perl and doesn't need to be compiled you can just put it in your application's lib folder and use it as normal.
We can install all perl modules both from and even with your terminal in ubuntu. If you are using a ubuntu server then execute the following command ,
'sudo apt-get install "perl_module"'
The modules which you want just give the name in "perl_module" means If you want to install Apache2::Cookie it will be in "libapreq2" so you have to give like,
"sudo apt-get install libapreq2"
I, as others have would highly suggest using CPAN.pm. It is a breeze to use and can resolve any dependencies associated with the module you need automatically.
On the other hand, I would suggest that you read the perlmodinstall document over at perldoc as it gives details on other os' as well.
Regards,
Jeff
If you're asking this because you're having problems with CPAN... you're probably running out of RAM that's why you can't use CPAN.
Maybe you don't have a swap file. Try this:
$ sudo su
# dd if=/dev/zero of=/swap bs=1M count=1k # create a 1GB file
# mkswap /swap
# swapon /swap
Otherwise... stop some services.
$ sudo service mysql stop
$ sudo service nginx stop
...And try again
$ cpan install CPAN
$ cpan install MIME::Lite::TT::HTML
Related
While loading necessities into my crouton, apt-get recommended that I install libtemplate-perl. This seemed a jolly idea, and I obeyed.
Reading this answer, I see a fellow traveler install Plack and Starman via CPAN, but then use apt-get to install Dancer.
Minutes before reading said answer, I had installed Dancer via CPAN. And it had worked. It had worked real good!
What happens differently when I install a CPAN package via a non-CPAN package manager? Are there pitfalls I need to be wary of because my libtemplate-perl came from apt-get, or my Dancer came from CPAN?
On Debian or Debian based distros like Ubuntu, CPAN (/usr/bin/cpan utility) installs modules into /usr/local/lib/ by default. And Debian packages keep their files in /usr/share/perl5/ and /usr/lib/perl5/.
It's a better way to choose dh-make-perl tool to package any CPAN distribution not available in your apt repositories, to avoid making mess (serious risk of conflict between apt and CPAN):
dh-make-perl --build --cpan Some::Module
dpkg -i some-module*.deb
Also check out about local::lib and perlbrew.
A lot of tutorials, Stack Overflow answers, walk throughs, etc. will not want to assume that you know how to use /usr/bin/cpan and will instead suggest that you use your system's package manager, which you are more likely to be familiar with.
This is especially true if you are using a tool written in a particular language, but you don't know that language. For example many people wouldn't care whether crouton is written in Perl, Python or Lisp, they just want a tool they can use. Your average Debian or Ubuntu user is more likely to be familiar with apt-get than with cpan.
If you are looking to program in Perl I recommend installing things by cpan, using perlbrew and/or local::lib. If you are just looking to install a tool you can use, I would recommend using apt-get.
Additionally apt-get has the advantage that non-Perl dependencies will be installed automatically. For example the CPAN module XML::LibXML requires that the libxml2 headers are available on the system; the CPAN distribution has no way of stating that as a dependency, and will simply fail on install if it can find the headers to link against. The Debian package can actually specify that libxml2 is a dependency, and will install the dependency automatically for you.
Despite that if you are looking to use XML::LibXML as a Perl programmer, I would recommend installing it with cpan and installing the libxml2 package via apt-get. Having all your Perl modules installed in the same place - again, via perlbrew or local::lib - will help you keep your sanity in the future. CPAN is preferable to apt-get in this case because not all distributions have been packaged for Debian, and so you get a lot more options if you use CPAN directly.
In summary: TIMTOWTDI ;-)
Another difference to mention that I don't see in other answers, is that if you use CPAN to install a module then the module version you get will be set, until you decide to upgrade that module. Whereas, if you use apt and a later version appears in Debian at some point in the future, then apt-get upgrade will update it.
Maybe you want that, maybe you don't. It's neither necessarily an advantage, nor a disadvantage. Simply a difference to be noted.
The good things about apt-get are
that you can uninstall the packages afterwards should you need to
if you are maintaining any number of servers it is quicker to use apt-get as there is no building required
there are definite versions of packages which are tested for compatibility
The downsides are
not necessarily the latest version of packages
not all packages are available
apt-get installs are generally easier and better than cpan because of dependencies alone.
If you are so lucky as to need SOAP::Lite, for example, it is many dozens of dependencies, and a one-line "apt-get install libsoap-lite-perl".
It is sometimes not clear how Perl CPAN names map to their repository package names, but "apt-cache search " is your friend.
Another approach, that can be used for any distro in HOME install as simple user:
Pros
avoid conflicts
up to date version of perl and modules
when you reinstall, you keep your home/perl as-si
you can upgrade all installed modules with $ cpan -r
Cons
you need to upgrade Perl manually
How to
Edit ~/.bashrc or such, and add:
export PERL5LIB=~/localperl/lib/
export PATH=~/localperl/bin:$PATH
Then
source ~/.bashrc
Install latest Perl5 from sources: https://www.cpan.org/src/README.html
Now, you have an isolate Perl installation in your home.
Enjoy the power to install any libs via:
$ cpan -i Whatever::Module
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.
I'm trying to write a Perl script that will run as a mapper under Elastic MapReduce's Streaming capability. I'm trying to use Net::Amazon::S3 (or the supposedly more portable Amazon::S3) to do some extra I/O of files from and to S3. That module is not on the default AMI, so I'm trying to use CPAN in a bootstrap-action script to install it. The bootstrap script currently contains:
perl -MCPAN -e 'CPAN::Shell->install(Amazon::S3)'
however, after 15 minutes the bootstrap action has still not completed, so I assume it is waiting for some kind of input. I've looked around but have not found any examples of bootstrap-action scripts that load Perl modules. Can someone advise me on that?
Thanks in advance...
Copy ~/.cpan/CPAN/MyConfig.pm from a machine with a configured cpan.
Set cpan config option prerequisites_policy to follow.
Set env var PERL_MM_USE_DEFAULT to 1.
Found an easier and faster way. It looks like most CPAN modules are also available by apt-get. I have a bootstrap action script that now says:
#!/bin/bash -e
source /etc/profile
# Make sure we have all of the dependencies in place for our Perl script.
sudo apt-get install -y libjson-perl
sudo apt-get install -y liburi-encode-perl
Note that this does not load the S3 module I asked about in the original question. I have changed my code so that I don't need that capability anymore. However, Net::Amazon::S3 is available as libnet-amazon-s3-perl so
sudo apt-get install -y libnet-amazon-s3-perl
should do the job.
Credit goes to http://www.deepakg.com/prog/2009/01/cpan-modules-on-ubuntu-apt-get-vs-perl-mcpan/ for the info.
Yesterday I wanted to test some software and in the documentation it said, to install I just needed to type
cpan -i Software
I never used cpan, I just know that it is the perl package manager. (Is it..?) However, it turned out that I needed loads of dependencies, and stupid as I am, I just installed all of them. (First, I had to set up cpan which asked me lots of questions) Long story short, I just want to remove all of it again. I googled a bit, and it seems like cpan does not have an uninstall routine, especially for all the packages at once.
Can I just remove some directory or will I run into troubles?
the cpan command isn't really a package manager like apt-get is. It is more a tool that downloads and installs from CPAN (the site, or one of its mirrors). After it has finished this task it doesn't remember much about what was done before, at least not enough to remove previously installed modules, at least not reliably, cleanly or dependency-safely. (Update: After looking at App::pmuninstall, it can be used to handle dependencies, but it does so by connecting to outside (read: web) sources, which compute these separately, which is fine, but I stand by the previous statement that CPAN.pm doesn't do this.)
I used to worry about removing modules, but now I realize that most Perl modules take up so little room that I just don't worry about having a few extra modules installed that you will never use. So unless you are on a computer with a REALLY small disc, I would just let it be.
On Windows or if you are using a non-system Perl on Linux/Mac you could just remove Perl and reinstall it. I would not recommend this if you are using the system installed Perl on Linux/Mac however as you could break your OS doing this (you might be ok if you were careful, but not worth it to save a few Mb!).
In the future, you can easily install a local version of Perl using perlbrew, there are tutorials all over the web if the docs aren't sufficient (they should be). This also has the bonus of letting you play with the newest and greatest Perl versions, which your system likely doesn't come with yet. Then if you install a mountain of junk, or even break it doing something crazy, remove that version and reinstall/install a different version.
Another nice tool is cpanminus (or cpanm for short) which is a newer, more user friendly cpan tool. All the cool kids are using it.
You can uninstall individual modules with cpanplus (ships with Perl) like this:
cpanp uninstall SQL::Abstract
You can view all modules installed with the cpan script like this:
perldoc perllocal
Putting the two together:
for module in $(perldoc -u perllocal | grep -F 'C<Module> L<' | sed 's/^.*L<\(.*\)|.*>$/\1/') ; do
cpanp uninstall "$module"
done
I'm not sure about removing "all of it". But to remove a single module you can use App::pmuninstall with it's sole script pm-uninstall to uninstall modules. You might then be able to write some kind of script to recursively remove the deps.
If you can't use cpan any more because there are incompatible modules in you path, you can remove all installed modules by hand. For example, I upgraded from Fedora 22 to Fedora 23 and the Perl version changed. All modules installed previously via cpanm into /usr/local/lib64/perl5 did not work any more and prevented me from using cpanm.
$ cpanm --uninstall Apache::DBI
Attempt to reload Scalar/Util.pm aborted.
Compilation failed in require at /usr/share/perl5/vendor_perl/File/Temp.pm line 18.
...
I could solve this by moving that directory:
$ mv /usr/local/lib64/perl5 /root/usr-local-lib64-perl5
The name of that directory may vary on your system.
Carefull: If a module installed files outside of that directory, for example system library files, these files will remain there.
I will change Flimm's answer to use cpanm and optionally uninstall cpanm itself in the end of the script:
#!/usr/bin/env bash
for module in $(perldoc -u perllocal | grep -F 'C<Module> L<' | sed 's/^.*L<\(.*\)|.*>$/\1/' | sort | uniq) ; do
if [[ "$module" =~ "App::cpanminus" ]]; then
continue
fi
echo "Uninstalling $module..."
yes | cpanm --uninstall "$module"
done
cpanm --uninstall App::cpanminus
I think the best option is uninstall Perl and install it again.
I installed some Perl modules in my Linux machine. If I enter perldoc perllocal it shows a list of Perl modules installed in my machine, but now I don't need those Perl modules, so I want to remove them.
Does anyone know how to uninstall or remove those modules installed in Linux (debian 2.6.26)?
The Perl installers are just that... installers. They don't verify that they're not overwriting existing files, and they don't record precisely what they install. Therefore, they cannot uninstall. If you want a proper packaging system, you can't use the Perl installers.
If you use CPANPLUS to install a module, you can (at least in theory) also use it to uninstall it:
$ cpanp
...
> u Unwanted::Module
...
> q
$
The older CPAN module does not support an uninstall option. And, as Randal Schwartz notes, uninstalling modules is not always reliable.
Use cpanp (its uninstall is not limited to cpanplus-installed modules), or see ExtUtils::Packlist's modrm example.
Uninstall tools have historically been not readily provided because the install process is not robustly reversible, as Randal cautions.
As I've mentioned somewhere else on SO, my answer is to just leave them. There are VERY few Perl modules large enough to take up any actual space on you system. I'm not saying don't try if you really need the space, but if you don't ... its not worth it.
You can try App::pmuninstall
DESCRIPTION
App::pmuninstall is a fast module uninstaller. delete files from
.packlist.
App::cpanminus and, App::cpanoutdated with a high affinity.
I tried cpanp uninstall and it didn't work for me. I did find success using App::pmuninstall.
pm-uninstall [options] Module ...
pm-uninstall - Uninstall modules - metacpan.org