I want to install all available perl modules at once in Ubuntu.
Is such a thing possible?
Instead of installing everything, why not use CPAN::Mini to get them all on your local machine. Then you can install the ones you need when you need them.
As others have said, you probably don't want to.
Many modules are updated more frequently on CPAN than the Ubuntu repos
Some modules aren't in the repos at all.
Many modules will have dependencies you don't need.
If you ever need more than one environment, it's a problem (although to be fair, this is generally a much rarer occurrence with perl than with other ecosystems).
perlbrew and cpanm are lovely and don't require `sudo
It's not a replacement for proper dependency management as if you ever have a distro upgrade, not all packages may be provided next time.
... however, if you're determined, a very straightforward way would be to look at the output of
sudo apt-get search perl | sed -e 's/ - .*//'
... and if it's to your liking, run
sudo apt-get search perl | sed -e 's/ - .*//' | xargs sudo apt-get install
Personally, I'd probably stick a | egrep '-perl' | in there, too before the xargs, as you might get hits based on the description that don't represent actual perl modules.
[Answer based on "Why?" provided in comments]
Based on my personal experience:
Almost all perl modules required for serious development are available as ubuntu/debian packages
e.g. Net::DBus perl package is provided by libnet-dbus-perl ubuntu/debian package.
You may install ubuntu/debian packages and keeping system itself up to date will update your installed perl modules.
Related
I have a carton cpanfile. on servers on which I have sudo, I would be happy to install the latest versions of my modules globally instead.
do I write a script that removes the 'requires' and uses cpan -i (although I am concerned that I may have too many to fit the command line limit), or is this functionality already somewhere else?
If there is a cpanfile you can just run
$ cpanm --installdeps .
as root (with sudo) in the directory with the cpanfile and cpanm will read it and install your dependencies to whatever Perl is configured for this cpanm.
You can ignore carton for that completely.
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
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.
How do I update all my CPAN modules to their latest versions?
An alternative method to using upgrade from the default CPAN shell is to use cpanminus and cpan-outdated.
These are so easy and nimble to use that I hardly ever go back to CPAN shell. To upgrade all of your modules in one go, the command is:
cpan-outdated -p | cpanm
I recommend you install cpanminus like the docs describe:
curl -L https://cpanmin.us | perl - App::cpanminus
And then install cpan-outdated along with all other CPAN modules using cpanm:
cpanm App::cpanoutdated
BTW: If you are using perlbrew then you will need to repeat this for every Perl you have installed under it.
You can find out more about cpanminus and cpan-outdated at the Github repos here:
https://github.com/miyagawa/cpanminus
https://github.com/tokuhirom/cpan-outdated
An easy way to upgrade all Perl packages (CPAN modules) is the following way:
cpan upgrade /(.*)/
cpan will recognize the regular expression like this and will update/upgrade all packages installed.
For Strawberry Perl, try:
cpan -u
Try perl -MCPAN -e "upgrade /(.\*)/". It works fine for me.
upgrade
BTW there is a help command.
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