http://www.perlmonks.org?node_id=1215631


in reply to Re: Should cpanminus be part of the standard Perl release?
in thread Should cpanminus be part of the standard Perl release?

"perhaps it might be of benefit to provide (possibly as one or more tutorials or meditations) a comparison of cpanminus to other common CPAN clients, "

I'm working on something as a background task, which has a hefty section on this very subject. I'll keep you posted.

"and thinking that if one were experimenting with different CPAN clients how much space could be "wasted" in the process."

cpanm has it's advantages, one being speed, it's simply a lot faster. It's also much lighter on resources, where cpan dies, e.g. installing things on an embedded, or otherwise resource limited system.

  • Comment on Re^2: Should cpanminus be part of the standard Perl release?

Replies are listed 'Best First'.
Re^3: Should cpanminus be part of the standard Perl release?
by ikegami (Pope) on Jun 02, 2018 at 00:00 UTC

    cpanm has it's advantages, one being speed, it's simply a lot faster.

    How can that be? cpan and cpanm are simply front ends for the installers provided by the distributions.

      This isn't strictly true, both packages work differently, as the anonymonk has commented on. Shortly I'll be in a position to demonstrate some evidence/test cases.

      How can that be? cpan and cpanm are simply front ends for the installers provided by the distributions.

      Because it never tries to download  1,781,641 02packages.details.txt.gz and then unzip/load into a  44,652,400 sourcefiles.s2.39.c0.9133.stored or  21,497,461 Metadata or a  18,997,248 cpandb.sql

      These numbers are a 2-6 years old, thats when I switched to cpanminus away from cpanplus and rarely cpan