I'm finishing the first draft of Modern Perl: the book. Part of that process is clarifying the intended audience:
I assume readers have some familiarity with Perl. They should have it installed and should know how to write, edit, save, and run Perl programs. They don't necessarily have to have finished reading a tutorial such as Learning Perl or Beginning Perl, but they should be sufficiently familiar with programming to be able to follow along with examples.
I try not to assume complete knowledge of even basic constructs; I try to explain them in detail, as understanding subtleties of design and implementation are important to mastering the subject of Perl.
Part of that process is deciding what's important to cover and why. For example, any book which discusses modern Perl has to discuss the CPAN and CPAN clients and installation of distributions from the CPAN. (You can't get away with writing about modern Perl without recommending Moose or Try::Tiny, for example.)
I don't want to assume that readers have configured their CPAN client correctly, nor that they have installed distributions from the CPAN before. Yet I also don't want to write pages of tutorials on configuring CPAN.pm versus CPANPLUS. I'd rather link to a tutorial somewhere like on the Perl 5 Wiki and get on with the work of explaining how to understand Perl than how to perform system administration.
Then a couple of people said "Why don't you tell them to use cpanminus instead?"
That offers advantages, especially in its speed, its lack of output when things just work, and the lack of necessary configuration.
That also offers disadvantages, in that there's less documentation in the wild about how to use cpanminus. As well, it's a young project and may not prove as long-lived as the other clients. My final concern is about debugging failed builds, tests, or installations. Though that's not always easy or obvious for users to debug with the other CPAN clients, I wonder if the additional step of skimming the build.log created on a failed installation is one level of difficulty too much for users.
Then again, when things go right, cpanminus is so much easier to use, it's almost no contest.
Would you recommend that novices skip over CPAN.pm straight to cpanminus now?
I think maybe at the very first, to whet the appetite - but long run, it makes sense to configure and use cpan(plus). I find when sitting down at a box without cpan configured yet, it's just easier to use cpanm unless I'm planning on doing heavy development there. So maybe -- use cpanminus until it breaks, then it's time to learn cpan.pm, and hopefully you'll be more equipped to answer the configuration questions by then.
I do recommend cpanm to all regular perl users. The main reason is the verboseness factor.
When I get a request for help with something that involves having difficulties installing some module, most users have problems with all that output. With cpanm is much simpler, they just send me the build.log file.
My only reason to teach cpan.pm after that is to support CPAN::Mini and a local CPAN mirror. Thats the only reason I still use CPAN, I'm usually offline.
If you are on a totally new, clean setup, cpan versus cpanm is more about preference. However, once you introduce the possibility of running on a shared server that has been used (and hack on) for a while, I find cpanm gives more consistent results, and makes it easier to do the right thing, like install to a local::lib, etc.
I tend to use both, althought cpanm is nearly always what I reach for when I am working on our shared development server. That's due to the fact that cpan configuration on that machine is totally confused :)
john
With exceptions noted in the next paragraph, I'm skeptical as to who would want to read a book called Modern Perl who had not already worked her way through most of a book like Learning Perl. I.e., in what specific sense would a reader of your book be a novice?
And that leaves me at a loss as to how to answer your specific question on cpanm versus cpan|cpanplus. (For the record, I've never used cpanm and only heard of it for the first time a few weeks ago.)
Exceptions: I have two brothers, both of whom are programmers, but neither of whom regularly use Perl. One is a veteran C/Unix programmer who now works in what I believe is an overwhelmingly Java environment. Another works in a Win32/no-products-other-than-MS environment -- but he did work in an environment in past years where he had to fix up Perl programs now and then. I could see that they might be willing to read a book on 'modern Perl': "Alright, I'm skeptical that Perl is anything other than a niche language, but I'll take a look." If, in that case, they were motivated to actually try out some of the examples in the book, a CPAN client with zero installation overhead would be beneficial.
But wouldn't that assume that they could install via downloading the tarball and running the install commands manually (since using cpan|plus in that case would be cheating)?
If the targeted audience is novice level, I'd even go as far as recommending cpanm -n. novices don't need tests being run.