This question already has answers here:
Which cpan installer is the right one? (CPAN.pm/CPANPLUS/cpanminus)
(5 answers)
Closed 4 years ago.
What is the difference between the cpan/cpanm and cpm commands?
I'm perl-begginer. What I can use: cpan/cpanm or cpm? Thanks.
These are all different programs that essentially do the same thing. They install modules from the CPAN (Comprehensive Perl Archive Network) to your computer.
cpan is the utility that Perl brings to install modules. It can be used as a shell or a simple command line utility. It uses the module CPAN under the hood.
cpanp is the utility to use the CPANPLUS module. It also has an integrated shell, and in general is a bit faster than the classic cpan tool.
cpanm is a faster, less fully-featured CPAN client that comes with the App::cpanminus distribution. It does not have a shell, and is the de-facto standard today, as most people recommend using it. It's fast, easy to use and usually you don't have to care about what is happening behind the scenes. There's also the handy cpanm-reporter in a separate distribution, that you can use to send test reports of your installations to cpantesters.org, which will then show up on metaCPAN and in other places, so other people know whether a certain dist will work with their OS and Perl version.
cpm is yet another client to install modules from CPAN. It's relatively new and claims to be very fast. It uses Menlo under the hood, which is the new backend the author of cpanm is working on to replace the internals of that one. It does not have a shell.
If all you want to do is install modules, it really doesn't matter what you use. cpan will always be available, but once you're used to cpanm it starts feeling a bit tedious.
I suggest you use whatever you feel comfortable with.
Related
This question already has answers here:
Which cpan installer is the right one? (CPAN.pm/CPANPLUS/cpanminus)
(5 answers)
Closed 6 years ago.
What is the difference between the cpan and cpanm commands?
They both seem to install perl modules, so what is the difference?
cpan the CPAN shell has been shipped with Perl since about 1997. When you run it the first time it asks a bunch of questions and saves the answers in a config file. Then you can install a module by running:
cpan -i Module::Name
The shell provides other commands for searching CPAN and looking inside distribution files.
A project to create a newer, better and more featureful CPAN shell called CPANPLUS (cpanp from the command-line) was started by Jos Boumans, but it was never quite completed to the point where the original vision had been realised.
Meanwhile MIYAGAWA decided that cpanp was trying to do too much and what the world really needed was a simpler shell that did less and asked fewer questions (ideally none at all). He created App::cpanminus which provides the cpanm command and does exactly what he intended. You can use it to install a module (and all the module's dependencies) with a command like:
cpanm Module::Name
The main difference between the two is that if you have Perl you should already have the cpan command. Whereas you won't have cpanm unless/until you install it.
Most modern Perl users prefer cpanm for it's simplicity and mainly, brevity of output.
Using cpan can result in hundreds of lines of output as it shows you everything it's doing: downloading, checksum, running installer, parsing, loading, the list goes on. The same applies to every dependency.
cpanm on the other hand tells you what it is doing in a more terse and general way, that is: Fetching, Configuring, Building and testing, Done.
So the main difference in usage is that cpanm suppresses a lot of (typically) irrelevant information. Sometimes when a module fails, you might want more information. There's a -v|--verbose flag that essentially shows you everything cpan would.
Also, some modules that require user input may seem to 'hang' when you try to install them. That's because the output that's asking you to type something is suppressed. You can use the --interactive (or --verbose) flags to work around that.
For a comparison of the output, see slides 35-39 here
or slides 37-41 here. (These are from the same presentation. I'm just duplicating the links in case one goes off line.)
I've done some research and it seems like ActivePerl had issues with earlier releases of it's product with certain CPAN modules not installing properly. However, I'm running the 5.14.x version and I've not had any problems.
According to some quotes I've seen:
ActivePerl is 100% compatible with the reference distribution of Perl.
Code tested with ActivePerl will run on any Perl installation that has the appropriate extensions installed.
I assume that the first statement refers to the standard modules you get with the Perl installation and for the second, I'm not sure what they are saying?
In any event, is there any way to find out how compatible ActivePerl is with the current CPAN modules or is that something that isn't known? I just don't want to spend time with it, only to have to switch to something like Strawberry Perl next month to avoid CPAN module build failures for the more common modules.
If ActivePerl is compatible with say 80% or higher with the CPAN modules I would feel more comfortable about using it, but I couldn't find any information on this.
I doubt a generic statistic will be that useful. In general I would expect all "pure perl" modules should work more or less out of the box. Keep in mind however that certain perl modules really are interfaces to lower level linux/unix style shared libraries (dlls in Windows terms), where availability is less certain. In my experience (having written a few perl applications being hosted on Windows, against my advice) most things will work, and/or are fairly easy to work around, and both ActiveState and Strawberryperl seem to have decent support for most common modules.
The first statement doesn't refer to modules at all. It says that ActivePerl is not based on Perl, it is Perl. As such, anything that will run on Perl will also run on ActivePerl.
This also means that all modules on CPAN are compatible with ActivePerl since ActivePerl is Perl.
Whether a module is compatible with Windows is an entirely different question, and it can only be answered on a module-by-module basis.
The second statement points out that if you had a script or module that runs on a pristine ActivePerl, it might not necessarily run on a pristine Perl because ActiveState includes modules in its distribution that aren't core modules (e.g. LWP). But all you'd need to do to make the script or module run on the other distribution is to install those modules.
You can check on the availability of PPM modules at http://code.activestate.com/ppm/. For example, one module that doesn't work well through PPM is PAR::Packer.
There are multiple installers for cpan modules available; I know of at least CPAN.pm (comes with perl,) CPANPLUS, and cpanminus.
What is the difference between the three?
What situations call for using one over the other?
Are there other module installers I should know about?
CPAN.pm (cpan) is the original client. It comes with Perl, so you already have it. It has the most features. It has a lot of configuration options to customize the way it works, though virtually everyone accepts the default installation. It integrates easily with local::lib.
cpanminus (cpanm) is an attempt to make a zero-configuration client that automatically does the right thing for most users. It's also designed to run well on systems with limited resources (e.g. a VPS). It doesn't come with Perl, but it's easy to install. It integrates easily with local::lib.
Its biggest limitation is its lack of configuration. If you want to do something unusual, it may not support it.
CPANPLUS (cpanp) is an attempt to make a CPAN API that Perl programs can use, instead of an app that you use from the command line. The cpanp shell is more of a proof-of-concept, and I don't know of any real advantages to using it.
In summary, I'd recommend either cpan or cpanm. If you have trouble configuring cpan, try cpanm. If your situation is unusual, try cpan.
It's impossible answer this question because it is too subjective. :)
From my point of view: cpanm is the simplest way install perl modules. You can install cpanm with:
curl -L http://cpanmin.us | perl - --sudo App::cpanminus
and after it you can install modules with simple:
cpanm Some::Module
You can use cpanm for mirroring (part of) CPAN to you local machine too, so IMHO cpanm is the best for the most common CPAN needs.
Are there other module installers I
should know about?
If you're using a Linux distribution that packages CPAN modules, then it's worth using their package installation program to install modules. For example, Ubuntu/Debian have a huge number of CPAN modules that you can install using 'apt' and Red Hat/Centos/Fedora have a number that you can install using 'yum'.
CPAN is the standard. cpanminus (cpanm) asks fewer questions (best most of the time). I don't know anyone that uses cpanplus.
Since what these modules do is download, compile and install (place files in correct places) they all should do the same task. Some of the difference has to do with the permissions level you have. Perhaps you want to install some things local to your user and some things globally then you need a finer adjustment. Developers may also need to control/interrupt the process for debugging etc.
For daily use, use cpanm, unless you are too lazy to install it, then CPAN is fine.
cpanm uses much less memory. This makes it a better choice for environments where RAM is limited, such as shared hosting servers, where regular cpan might die before completing installation task, due to attempting to use more than available memory.
According to cpanm's (1.7044) documentation "When running, it requires only 10MB of RAM"
I've written any number of perl modules in the past, and more than a few stand-alone perl programs, but I've never released a multi-file perl program into the wild before.
I have a perl program that is almost at the beta stage and is going to be released open source. It requires a number of data files, as well as some external perl modules -- some I've written myself, and some from CPAN -- that I'll have to bundle with it so as to ensure that someone can just download my program and install it without worrying about hunting for obscure modules.
So, it sounds to me like I need to write an installer to copy all the files to standard locations so that a user can easily install everything. The trouble is, I have no idea what the standard practice would be for this. I have found lots of tutorials on perl module standards, but none on perl program standards.
Does anyone have any pointers to standard paths, installation proceedures, etc, for perl programs? This is going to be complicated by the fact that the program is multi-platform. I've been testing it in Linux, but its designed to work equally well in Windows.
Take a look at PAR and PAR::Packer. You can bundle all of your requirements (even non-Perl requirements) into one file. With PAR::Packer, the user doesn't even need to have Perl installed for it to work.
You might also look at how the various App::* distributions are setup.
The standard installers for modules (ExtUtils::MakeMaker, Module::Build, Module::Install) also work the same way for scripts.
Using such a standard Perl tool will help you to:
distribute your application on the
CPAN (and you'll benefit from
automated tests on various platforms
by CPAN Testers), and so your app
will be installable (with all its dependencies) from the CPAN
shell
help packagers of Linux/BSD distributions to make packages for your product
I want to use Apple's or RedHat's built-in Apache but I want to use Perl 5.10 and mod_perl. What's the least intrusive way to accomplish this? I want the advantage of free security patching for the vendor's Apache, dav, php, etc., but I care a lot about which version of Perl I use and what's in my #INC path. I don't mind compiling my own mod_perl.
Build your version of Perl 5.10 following any special instructions from the mod_perl documentation. Tell Perl configurator to install in some non-standard place, like /usr/local/perl/5.10.0
Use the instructions to build a shared library (or dynamic, or .so) mod_perl against your distribution's Apache, but make sure you run the Makefile.PL using your version of perl:
/usr/local/perl/5.10.0/bin/perl Makefile.PL APXS=/usr/bin/apxs
Install and configure mod_perl like normal.
It may be helpful, after step one, to change your path so you don't accidentially get confused about which version of Perl you're using:
export PATH=/usr/local/perl/5.10.0/bin:$PATH
You'll want to look into mod_so
I've done this before. It wasn't pretty, but it worked, especially since vendor perl's are usually 2-3 years old.
I started with making my own perl RPM that installed perl into a different location, like /opt/. This was pretty straight forward. I mostly started with this because I didn't want the system utilities that used perl to break when I upgraded/installed new modules. I had to modify all my scripts to specify #!/opt/bin/perl at the top and sometimes I even played with the path to make sure my perl came first.
Next, I grabbed a mod_perl source RPM and modified it to use my /opt/bin/perl instead of /usr/bin/perl. I don't have access to the changes I made, since it was at a different gig. It took me a bit of playing around to get it.
It did work, but I'm not an RPM wizard, so dependency checking didn't work out so well. For example, I could uninstall my custom RPM and break everything. It wasn't a big deal for me, so I moved on.
I was also mixing RPM's with CPAN installs of modules (did I mention we built our own custom CPAN mirror with our own code?). This was a bit fragile too. Again, I didn't have the resources (ie, time) to figure out how to bend cpan2rpm to use my perl and not cause RPM conflicts.
If I had it all to do again, I would make a custom 5.10 perl RPM and just replace the system perl. Then I would use cpan2rpm to create the RPM packages I needed for my software and compile my own mod_perl RPM.