CPAN Improvements, Take 2.
By J. Shirley on February 2, 2010 5:54 AM | PermalinkI'm now revisiting my CPAN post from before. The illustrious charsbar commented about CPAN options that certainly do a good job hiding the things you don't need to see, except for when you need to see them.
I thought I'd give some examples to show how these options are not good enough, and not really what I'm after.
First, imagine the case of local::lib being setup. Then you run CPAN (1.9402) after local::lib aliases are setup; As expected, right after 'cpan', you are met with a configuration prompt. It tells you that you have no access to write to /root/.cpan. Of course, because we're good developers and use local::lib. This works well, the user configuration is created but then there is a problem:
That wasn't what we wanted, right? Here's another point, and an easy bug. If CPAN knows it created a user configuration, automatically reload it. Minor nit. CPAN.pm has a plethora of open bugs, it's daunting to just file a bug because you don't want to file a dupe. After I write this post, I'll see about that.nolock_cpan[1]> o conf halt_on_failure yes
halt_on_failure [yes]
Catching error: "/etc/perl/CPAN/Config.pm is not writable at /usr/local/share/perl/5.10.0/CPAN/HandleConfig.pm line 286\cJ\cICPAN::HandleConfig::commit('CPAN::HandleConfig') called at /usr/local/share/perl/5.10.0/CPAN/HandleConfig.pm line 213\cJ\cICPAN::HandleConfig::edit('CPAN::HandleConfig', 'halt_on_failure', 'yes') called at /usr/local/share/perl/5.10.0/CPAN/Shell.pm line 393\cJ\cICPAN::Shell::o('CPAN::Shell', 'conf', 'halt_on_failure', 'yes') called at /usr/local/share/perl/5.10.0/CPAN.pm line 375\cJ\cIeval {...} called at /usr/local/share/perl/5.10.0/CPAN.pm line 372\cJ\cICPAN::shell() called at /usr/local/bin/cpan line 198\cJ" at /usr/local/share/perl/5.10.0/CPAN.pm line 391
CPAN::shell() called at /usr/local/bin/cpan line 198
So, you exit cpan and restart, it says the other process isn't responding. Overwrite it? Sure! Now we're in business. This is not a good user experience. So far it looks like everything is broken, and there isn't anything shown to the user that CPAN is ready to do what it is supposed to do.
Now that we're here, setting the various options charsbar pointed out works. As expected, now just the "perl Makefile.PL" is loud and the installation prompts fill the backlog. It is much improved, as the more important details are present. The screen is still filled with all sorts of information that I don't need, or even want. Test passes, etc. The verbosity options merely affect CPAN.pm operations, and not the actual building. I want a very nice filter.
When things fail, the situation is no different regardless of the CPAN options. I have pages and pages of text to deal with, the only benefit is that now I aborted on a failure. I have no way to jump in and attempt to resume after fixing this error.
Here's the output of the first test failure (namespace::clean) that just stops the install in its tracks:We're still not in any position to help the user. What do to from here? Well, the only thing is to see cpan-testers results. This doesn't help anybody succeed.t/07-debugger.t ..........
Loading DB routines from perl5db.pl version 1.32
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(t/07-debugger.t:26): package Foo;
Unknown error
Compilation failed in require at /home/ems/perl5/lib/perl5/Term/ReadLine/Perl.pm line 63.
at /home/ems/perl5/lib/perl5/Term/ReadLine/Perl.pm line 63
Term::ReadLine::Perl::new('Term::ReadLine', 'perldb', 'GLOB(0x8465e28)', 'GLOB(0x83ba9e8)') called at /usr/share/perl/5.10/perl5db.pl line 6073
DB::setterm called at /usr/share/perl/5.10/perl5db.pl line 2237
DB::DB called at t/07-debugger.t line 26
Test::Builder::CODE(0x8429fc8)(/home/ems/perl5/lib/perl5/Test/Builder.pm:2426):
2426: $Test->_ending if defined $Test;
Attempt to reload Term/ReadLine/readline.pm aborted.
Compilation failed in require at /home/ems/perl5/lib/perl5/Term/ReadLine/Perl.pm line 63.
END failed--call queue aborted at t/07-debugger.t line 63.
at t/07-debugger.t line 63
Attempt to reload Term/ReadLine/readline.pm aborted.
Compilation failed in require at /home/ems/perl5/lib/perl5/Term/ReadLine/Perl.pm line 63.
END failed--call queue aborted at t/07-debugger.t line 63.
at t/07-debugger.t line 63
Test::Builder::DESTROY(/home/ems/perl5/lib/perl5/Test/Builder.pm:317):
317: my $self = shift;
t/07-debugger.t .......... Dubious, test returned 9 (wstat 2304, 0x900)
No subtests run
t/08-const-sub.t ......... ok
Test Summary Report
-------------------
t/07-debugger.t (Wstat: 2304 Tests: 0 Failed: 0)
Non-zero exit status: 9
Parse errors: No plan found in TAP output
Files=9, Tests=73, 0 wallclock secs ( 0.02 usr 0.03 sys + 0.42 cusr 0.07 csys = 0.54 CPU)
Result: FAIL
Failed 1/9 test programs. 0/73 subtests failed.
make: *** [test_dynamic] Error 255
FLORA/namespace-clean-0.13.tar.gz
/usr/bin/make test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports FLORA/namespace-clean-0.13.tar.gz
Running make install
make test had returned bad status, won't install without force
Stopping: 'install' failed for 'F/FL/FLORA/namespace-clean-0.13.tar.gz'.
Failed during this command:
FLORA/namespace-clean-0.13.tar.gz : make_test NO
So, even with the verbosity options set to the quietest setting, it does nothing for the output of the various Makefile.PL/Build.PL outputs. There isn't any assistance offered, or even help for the user to plug into a google search.
If these modules are on the CPAN, it is reasonable to assume a standard of behavior. Such that my desired output is feasible: * Fetching {module name}... ok
* Unpacking {module name}... ok
* Following dependencies... ok
* Testing {module name}... ok
The other thing would be to have a full dependency list calculated at the start, so it can be determined what packages need to be installed and in what order, just to suppress the enter-mashing problem.
I suppose that a lot of this could simply be an output processor for the make/install loop, and then other CPAN loops.
If the Perl community wants to tout "the CPAN" as the killer feature, then CPAN.pm needs to be a killer feature.
I'm hoping the next version of a CPAN shell keeps this in mind, and it ultimately boils down to these priorities:
- Don't inundate the screen with useless messages on success.
- Don't be terse and not include messages on failure.
- Help the user.
Developers may find marketing to be slimey and sleazy, but understand that having a tool that insults and frustrates the user is just as much marketing as having a beautiful website with quality typography and information architecture.
I'll get off my soapbox now.