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

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 (Patriarch) 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.	[reply]
Re^4: Should cpanminus be part of the standard Perl release? by marto (Cardinal) on Jun 24, 2018 at 16:05 UTC
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.	[reply]
Re^4: Should cpanminus be part of the standard Perl release? by Anonymous Monk on Jun 07, 2018 at 22:32 UTC
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	[reply] [d/l] [select]

In Section Past Polls