[rant] Of the suckage of the CPAN shell

Actually the system is functioning - there are workarounds for everything I mention. But it shouldn't annoy the living Shub-Internet out of me, either.

First, accolades. The manual configuration has improved greatly from the last time I looked at it. It doesn't ask questions anymore that only an insider can answer, and it's short and finished in three minutes tops. Also, now there exists a very decent system to pick CPAN mirrors.

I'm interested in doing a hands-off approach in installing modules, fire and forget if you will. CPAN is a package manager, so it should be possible. prerequisites follow is a good start, but have a look at where I had to babysit installations recently:
Term::ReadLine
```
Enter arithmetic or Perl expression: exit
```
YAML
```
*** WARNING ***

This release breaks compatibility with versions earlier than version 0
+.60 of
YAML::Syck and YAML.pm when serializing blessed references.

See the COMPATIBILITY file for more information.

Continue installing YAML.pm? [y]
[download]
```
Note: those two following are although I have set prerequisites follow!
Best
```
- Test::Exception ...missing.
==> Auto-install the 1 mandatory module(s) from CPAN? [y]
[download]
```
Method::Alias
```
==> ExtUtils::AutoInstall 0.49 required. Install it from CPAN? [Y/n]
[download]
```
ExtUtils::AutoInstall (twice) and Module::Signature
```
==> Auto-install the 1 optional module(s) from CPAN? [n]
[download]
```
Petal::Utils, Pod::Coverage, probably others
```
This module requires Module::Build to install itself.
  Install Module::Build now from CPAN? [y]
[download]
```
I happily confirmed that last question and got 15 minutes of my life stolen. Module::Build namely by default configures, builds and installs itself without C support, which is necessary if you want to install XS modules with it later. And who does not? Anyway, M::B barfed chunky bits all over me, and I had to chase its dependencies and then install it again.
There's no mechanism to follow dependencies for optional packages and packages used in testing. I am interested in having good testing, so when I notice that tests are skipped because some modules (e.g. Test::Pod::Coverage, Test::Pod, Expect) are not installed, I must SIGINT like a madman. So after satisfying these dependencies first, and then attempting to build again, this happens:
```
make: *** [test_dynamic] Error 255
  /usr/bin/make test -- NOT OK
Running make install
  make test had returned bad status, won't install without force
[download]
```
or
```
  Make had some problems, maybe interrupted? Won't test
Running make install
  Make had some problems, maybe interrupted? Won't install
Running make for ...
  Is already unwrapped into directory ...
  Has already been processed within this session
[download]
```
I can only fix that by quitting the shell and starting again.
In case I don't catch a testing dependency quickly enough, those tests are skipped and the module installs without further ado. I can later repeat the test with test Foo::Bar, which then reveals brokenness. Now of course the module is already installed.
Luckily, I've never encountered this situation. But what am I supposed to do if?
There's no uninstall offered from the shell. Workaround is mentioned in the CPAN FAQ, but you have to know first that it's not called uninstall, or delete, or purge, but remove.
This crypto signing business is beyond the nerve of mere mortals.
```
WARNING: This key is not certified with a trusted signature!
Primary key fingerprint: 50A0 ED26 8AA2 95BD 2CA0  411E EC80 39F0 A317
+ C15D

  CPAN.pm: Going to build A/AN/ANDK/CPAN-1.87.tar.gz

Importing PAUSE public key into your GnuPG keychain... done!
(You may wish to trust it locally with 'gpg --lsign-key 450F89EC')
[download]
```
Did you notice the red herring? 50A0... is actually the fingerprint of a totally different key, 0xA317C15D, so signing the PAUSE key has no effect, but I'm never going to find out because the key servers allow me to search keys by name, ID or hash, but not by fingerprint.
There's too much crap on the screen. That's partially the fault of GNU make, I guess. I want a setting for verbosity (and a pony), with the default to show warnings and more severe only.
My rant actually had three more items on the list initially, but reading through the scrollback of my CPAN sessions carefully, I could fix those problems myself or it turned out they weren't in the first place. It would have been easier on my blood pressure with less cruft to wade through.
Last and least, that goddamn install package. If you have this oscure module installed, you fell victim to it, too. How did you get it?
sudo cpan install Foo::Bar must actually be sudo cpan Foo::Bar.

You tell me now where I'm wrong.

READMORE added by Arunbear

Comment on [rant] Of the suckage of the CPAN shell Select or Download Code

Replies are listed 'Best First'.
Re: [rant] Of the suckage of the CPAN shell by xdg (Monsignor) on Jul 10, 2006 at 19:12 UTC
Wow. Let me say that I am not the Anonymous Monk, but I shared this same endless pain over and over in assembling Strawberry Perl. But it's not really the CPAN shell's fault, solely. It's module specific behaviors and Makefile.PL's. What is the fault of CPAN.pm is a totally opaque API that makes it very difficult for other things to integrate well with it. Update: Let me add that if the Makefile.PL or Build.PL use the `prompt()` routine (from either ExtUtils::MakeMaker or Module::Build), then you can have it automatically return the default value by setting the `PERL_MM_USE_DEFAULT` environment variable to a true value. Update 2: Also, Term::Readline::Perl respects the `AUTOMATED_TESTING` environment variable. Of course, these only conventions, but they aren't totally uncommon. -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply] [d/l] [select]
Re: [rant] Of the suckage of the CPAN shell by Corion (Patriarch) on Jul 10, 2006 at 18:26 UTC
I think only the crypto signing thing relates to the cpan shell. The rest is up to the Makefile.PL of the packages you're using. And these are completely annoying, especially those using Module::AutoInstall and Module::Build as well. But you obviously haven't tried to test mod_perl without having Apache installed - it will happily ask the same question over and over again...	[reply]
Re^2: [rant] Of the suckage of the CPAN shell by jhourcle (Prior) on Jul 10, 2006 at 18:43 UTC
For the stupid Makefile.PL questions -- I think that's what 'inactivity_timeout' is for. Here's what you get when you do an 'o conf init' `Sometimes you may wish to leave the processes run by CPAN alone without caring about them. Because the Makefile.PL sometimes contains question you're expected to answer, you can set a timer that will kill a 'perl Makefile.PL' process after the specified time in seconds. If you set this value to 0, these processes will wait forever. This is the default and recommended setting. Timeout for inactivity during Makefile.PL? [0]` [download]	[reply] [d/l]
Re^3: [rant] Of the suckage of the CPAN shell by Corion (Patriarch) on Jul 10, 2006 at 18:45 UTC
Yes - except that it doesn't work for me on Win32, because it's implemented via `alarm()` last time I looked ;)	[reply] [d/l]
Re: [rant] Of the suckage of the CPAN shell by chromatic (Archbishop) on Jul 10, 2006 at 20:22 UTC
There's no mechanism to follow dependencies for optional packages and packages used in testing. Agreed. There's no reason to ship POD sanity and coverage tests, except to raise your Kwalitee and annoy your users. At least, there's no reason to run them as part of the default set of tests. (I exaggerate; they might be valuable if you autogenerate your POD in such a way that it might end up invalid or missing on a different platform. I've never seen that though.)	[reply]
Re: [rant] Of the suckage of the CPAN shell by diotalevi (Canon) on Jul 10, 2006 at 21:12 UTC
You know what sucks even more than CPAN.pm? CPANPLUS.pm. Wow. I didn't keep a log of my installation like you did for CPAN.pm but it's way harder to get that beast going than the CPAN shell. What sucks even more is that I installed it to get the cpansmoke script and it turns out that it's been removed from CPANPLUS altogether. I think it's now called CPAN::YACSmoke. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]
Re^2: [rant] Of the suckage of the CPAN shell by brian_d_foy (Abbot) on Jul 11, 2006 at 17:24 UTC
`sudo cpan install Foo::Bar` must actually be `sudo cpan Foo::Bar`. Installing modules with `cpan` is the most frequent task, so you don't have to give it any command. Just give it the module names and let it go. I think its pretty clear from the documentation how you are supposed to call it. If there's something that it's not doing correctly, send me a bug report. I'm not sure why you have to quit the CPAN shell when it doesn't see optional modules. If Test::Pod::Coverage isn't there, who cares? Why do you let that mess up your life? That module is designed and intended to be optional. It doesn't test any code, so it doesn't really matter. If it fails, you probably don't want to stop the module install process. We specifically make those modules optional so you don't have to install them and it's not more work for you. If you run across a distro that doesn't declare its prereqs correctly or completely, that's not the shell's fault and you should report it as a bug of the distro. -- brian d foy <brian@stonehenge.com> Subscribe to The Perl Review	[reply] [d/l] [select]
Re^3: [rant] Of the suckage of the CPAN shell by TilRMan (Friar) on Jul 12, 2006 at 03:36 UTC
I've fallen for the 'cpan install' feature so many times without knowing why that I've just gotten in the habit of using `perl -MCPAN`. Now that I know why, I'd say the interface of cpan(1) violates the Principle of Lease Surprise, but that's just me. To illustrate: `$ perl -MCPAN -e shell # Right cpan> install Foo $ perl -MCPAN -e 'install Foo' # Right $ cpan # Right cpan> install Foo $ cpan install Foo # WRONG!` [download] I think a good compromise would be to special case the distro called 'install' and have cpan(1) refuse to install it unless the -i option is thrown explicitly (or if it is the only item listed, perhaps). And a nice helpful error message if it isn't, such as: It appears you may be trying to install the 'install' distribution. If this is what you want, use the -i flag as well. If what you really want is to install the '`@ARGV[1..-1]`' module(s), use the -i flag and omit `install`. Read perldoc cpan for more information. And then put a lengthy discussion in the manpage. I think a good solution would involve the compromise above, plus the deletion of the 'install' distribution, plus the lifetime imprisonment of anyone who ever does or ever has uploaded a distribution called 'install'. But that's just me.	[reply] [d/l] [select]
Re^3: [rant] Of the suckage of the CPAN shell by xdg (Monsignor) on Jul 11, 2006 at 19:12 UTC
sudo cpan install Foo::Bar must actually be sudo cpan Foo::Bar. Installing modules with cpan is the most frequent task, so you don't have to give it any command. Just give it the module names and let it go. I think its pretty clear from the documentation how you are supposed to call it. If there's something that it's not doing correctly, send me a bug report. You have to know what he's talking about to get this one. It's not a bug, it's a "feature". Look at http://search.cpan.org/search?query=install&mode=module. If you mistakenly type "`cpan install Foo::Bar`", you wind up installing the distribution `junoscript-perl`. It's easy to make the mistake and type "install" and many people don't even notice that junoscript has also been installed if they aren't watching closely. -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply] [d/l] [select]
Re: [rant] Of the suckage of the CPAN shell by perrin (Chancellor) on Jul 10, 2006 at 19:59 UTC
These are mostly complaints about Makefile.PLs and the generally loose way that module testing and installation is (not) specified. Have you checked to see if any of your actual shell ease-of-use complaints are addressed in CPANPLUS?	[reply]
Re^2: [rant] Of the suckage of the CPAN shell by Anonymous Monk on Jul 11, 2006 at 19:03 UTC
CPANPLUS is worse. Installing a large bundle makes it appear as if it hangs. The shell does not remember command history between sessions. It also just gives GPG fingerprints. I cannot look up a key with that. When I `t Foo::Bar` and it passed, I cannot `i Foo::Bar` because: `Not in MANIFEST: blib/arch/.exists Not in MANIFEST: blib/arch/auto/Foo/Bar/.exists Not in MANIFEST: blib/bin/.exists Not in MANIFEST: blib/lib/auto/Foo/Bar/.exists Not in MANIFEST: blib/lib/Foo/Bar.pm Not in MANIFEST: blib/man1/.exists Not in MANIFEST: blib/man3/.exists Not in MANIFEST: blib/man3/Foo::Bar.3pm Not in MANIFEST: Makefile Not in MANIFEST: pm_to_blib ==> MISMATCHED content between MANIFEST and distribution files! <==` [download] Quitting the CPANPLUS shell, unlike CPAN, does not help purge here. It remembers the mess instead of starting clean over. I have to `z Foo::Bar` and `make distclean` before I can `i Foo::Bar` again. Aaargh. `[ERROR] Could not send 'fail' report for 'Foo-Bar-0.01': Test::Reporte +r: Unable to send test report [ERROR] Failed to send test report for 'Foo::Bar'` [download] And why? Give me a reason, so I can fix it!	[reply] [d/l] [select]
Re: [rant] Of the suckage of the CPAN shell by tilly (Archbishop) on Jul 12, 2006 at 00:58 UTC
Two more annoyances for you. First, if the first CPAN mirror is down, with every single file CPAN fetches, you have to wait for it to rediscover that it can't fetch from that mirror. Why not have it on the next file rotate its list of mirrors so that it first tries the one that actually worked last time? Second, on Ubuntu if I do `sudo perl -MCPAN -e shell`, the crypto bit gets all unhappy because root tries to access my user's keychain and decides it shouldn't. I have to `(sudo su; perl -MCPAN -e shell)` instead. Very minor, but if I'm listing annoyances, why not list it?	[reply] [d/l] [select]
Re: [rant] Of the suckage of the CPAN shell by CountZero (Bishop) on Jul 12, 2006 at 19:20 UTC
Last time I looked CPAN was just a Perl-module. So if you don't like it, just roll your own or patch it. Next we will have AM's complaining that some module only solves 99% of their homework and they therefore feel badly treated by this module writer! If you consider the alternative (doing the whole install by hand including downloading and untarring all packages, following all dependencies, running all tests, ...) CPAN is a god-given present to us Perl-programmers. CountZero "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law	[reply]
Re^2: [rant] Of the suckage of the CPAN shell by rhesa (Vicar) on Jul 12, 2006 at 21:51 UTC
Technically, you're right of course. But CPAN.pm is not your average run-of-the-mill Perl module. It's a central piece of our infrastructure, and almost everyone^* working with Perl uses it. I think we're entitled to place higher demands on it. ^BOCTAOE. But the Vanilla Perl efforts will come to the rescue of our Windows friends too ;)*	[reply]
Re^3: [rant] Of the suckage of the CPAN shell by CountZero (Bishop) on Jul 12, 2006 at 22:00 UTC
Perl being a community effort, we all share the responsability if something is not the way we like it. CountZero "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law	[reply]
Re^4: [rant] Of the suckage of the CPAN shell by rhesa (Vicar) on Jul 12, 2006 at 22:26 UTC


Pathologically Eclectic Rubbish Lister
	PerlMonks