Improving CPAN, make money and help Perl.
By J. Shirley on January 22, 2010 9:46 AM | PermalinkI have a new server to setup, which will be a staging and development environment. This means I'll be installing much more than is typical, and I figured it is a good chance to test the legs of Task::Kensho.
The first line summary is that I'm slightly disappointed, because there were failures in mid-stream and while it continued, it wasn't exactly intuitive as to the failure. One of my biggest complaints about working in any programming language is when you get ambiguous failure messages. Failures with messages "Can't locate namespace/clean.pm in..." followed by a tremendous deluge of test failure messages counts there. Especially when namespace::clean should have been installed.
Update: The bounty and details are at the bottom, but sartak is also throwing in $100. $200 to make a CPAN client that doesn't scare people. Lets do it, people.
And here is the long version. I setup a Linode 360, deployed Debian 5.0 on it. After it booted, I added my user account and setup sudo. Then proceeded down the path of having a working development environment:
sudo apt-get install perl mysql-server libdbd-mysql-perl lib-dbd-sqlite3-perl build-essential unzipIf you don't install unzip, CPAN can't find it and will error when it encounters a package that is zipped. Why people upload packages to the CPAN as a zip I'll never know, but that's their (silly) choice.
After this, (as root) I install local::lib
sudo su -
cpan local::libOn Debian 5.0, CPAN has the capability of automatically configuring itself. This is nice, and just works. So far so good.
Now, under my user account:
perl -Mlocal::lib >> .profile
. .profile
At this point, I can use CPAN as my user and install into my perl lib directory and not deal with anything on the system level. No more sudoing, so enter Task::Kensho.
cpan Task::KenshoHere you have a lot choices, but fortunately they are easy to understand. Since I'm working with DBIC and Catalyst, with lots of Moose, those were the choices I made - as well as selecting the various command-line options and other utilities for developing.
Unfortunately, the Moose section failed. Sub::Identity failed to download, thus blocking namespace::clean from installing, subsequently failing MooseX::Types and then I had a little storm of failure. This is quite frustrating, but I just ran "cpan namespace::clean" in another session and was able to install it properly the second time.
Now to be safe I installed MooseX::Types and MooseX::Types::Path::Class, since that was the point that it failed.
Here's an important bit. If I wasn't paying attention I would have no idea what failed, or why it failed. CPAN silently continued on to the next module and I had to scroll up to see the failures and only my experience with Perl and CPAN was able to allow me to continue.
Also, there is a lot of enter pushing. There are options to automatically follow, but because of failures like above I didn't set that. Good thing, or I wouldn't have everything installed.
I had the same issues with several other modules, mostly in the Task::Moose bundle. Each one, while installing separately, was successful; only when part of Task::Kensho did these fail. I don't mean this as a criticism of Task::Kensho, instead it is about the CPAN client.
It has messages that are quite specific:
Warning: Prerequisite 'Parse::Method::Signatures => 1.003012' for 'A/AS/ASH/TryCatch-1.002000.tar.gz' failed when processing 'F/FL/FLORA/Parse-Method-Signatures-1.003013.tar.gz' with 'make_test => NO'. Continuing, but chances to succeed are limited.Too specific, CPAN knows it is going to fail and instead of stopping to ask the user for help or doing something that will be useful, it continues on and buries the failures amidst dozens of lines of meaningless test failures.
It's not a terrible experience, but it is extremely verbose and the most important messages are hidden. You have to either decide between hitting enter constantly at each dependency step, and catching when things fail, or simply hope that things will succeed. In my experience, they won't succeed and as such I'm forced to press enter a lot and keep another session open so that I may install modules that fail by hand.
This is not an experience that a user who is new to Perl should endure.
In an effort to be constructive, here is how I envision a much better process.
CPAN has a default output mode that is not so verbose. I don't need to see the result of unpacking a module, the prerequisites that aren't found and the requirement list. I should instead see something like this:
* Fetching {module name}... ok
* Unpacking {module name}... ok
* Following dependencies...In the case of a failure, or an attempt to fetch a dependency that has failed to install, CPAN should immediately pause and ask the user what to do. The reasonable choices are: Attempt to refetch/install, Show Details or Abort. If you show details, it should show the entire log from the Unpack to the Failure.
I'm not familiar with CPAN internals, and don't really care to be. So, here's my offer to solve this problem.
$100 in cash, check or paypal, to anybody who gets a mode of CPAN working as described. The money is just a token, and I have no idea how long it will take to do this. It doesn't seem complex to simply reduce output and change that "Prerequisite failed when processing" message I listed above to something helpful. Maybe $100 is too little, but the point is you're helping the Perl community by making our most valuable tool more functional. Comments welcome to flesh this out, maybe other people are interested in matching additional funds to whoever can make CPAN not so daunting to new users.
I will test it in the same fashion as above, starting with a fresh debian 5.0 install and local::lib and whatever CPAN modules need to be installed for this to work. I will then fire off installing Task::Kensho.