Perl Noise Aggregator

use.perl.org goes offline

nobody@example.com (denny) — 2010-09-08T23:05:10Z

Pudge announced (http://use.perl.org/articles/10/09/08/2053239.shtml) yesterday that use.perl.org (http://use.perl.org/) will be going offline from today. He hopes to restore it as a static resource at a later date.A lot of the community has already migrated to the more attractive blogs.perl.org (http://blogs.perl.org/) anyway, so hopefully this shouldn't cause too much disruption.

Use.perl is going to die soon

nobody@example.com (brian d foy) — 2010-09-08T22:36:32Z

No, really. Chris Nandor is changing employers, so he won't have access to the machine that hosts use.perl after Friday. He's going to take a database dump with him and turn the site into a static site so the content will still be there for a bit, but eventually it's going to disappear. This might mean that a reboot, power outage, disk failure, or something else might means the current use.perl doesn't come back to life.

The Perl community was very fortunate that Geeknet (and all the other names they went by) allowed Chris to host the site. Use.perl was a test bed for slashcode, so whatever Slashdot did or wanted to do, that's what use.perl did. It was a good thing going for a long time, and many of us owe Chris a lot of beer for use.perl, even if we didn't always like slashcode.

Now it's time to figure out what to do without use.perl and all the links to various posts in there. The main goals are:

Links to URLs within use.perl continue to serve the same content
People get to keep their use.perl content if they'd like to do something else with it.

Since its slash, a lot of the stuff is dynamic. Since use.perl basically ran on autopilot, Chris doesn't have the bandwidth. Since use.perl won't be connected to his new employer's tasks, he'll have even less time for it. Maybe there's someone who has the bandwidth for it.

Some possible solutions we talked about:

Set up slashcode and serves the site dynamically. If hosting is a problem, talk to me. :)
Set up slashcode and serves the site statically. This might mean a caching layer that stores the computed page for every URL. I'm not sure if that will handle the Ajax stuff properly though.
Take the database dump and recreate the pages somehow.
Crawl the entire site and store the results as static pages.

One idea was to inject everything into blogs.perl.org. I don't know how that would work of if the blogs.perl.org team want to do that. It would require a very large URL rewriting component.

Use.perl is going to die soon

nobody@example.com (brian d foy) — 2010-09-08T22:13:42Z

Now it's time to figure out what to do without use.perl and all the links to various posts in there. The main goals are:

Links to URLs within use.perl continue to serve the same content
People get to keep their use.perl content if they'd like to do something else with it.

Some possible solutions we talked about:

Set up slashcode and serves the site dynamically. If hosting is a problem, talk to me. :)
Set up slashcode and serves the site statically. This might mean a caching layer that stores the computed page for every URL. I'm not sure if that will handle the Ajax stuff properly though.
Take the database dump and recreate the pages somehow.
Crawl the entire site and store the results as static pages.

One idea was to inject everything into blogs.perl.org. I don't know how that would work of if the blogs.perl.org team want to do that. It would require a very large URL rewriting component.

Hacking the Perl core for smarter push and pop

nobody@example.com (dagolden) — 2010-09-08T21:33:24Z

In a recent post, I said I wished that Perl's built in functions for array containers would work directly on references.

Rather than this (today):

# Assuming $data->{$key1}{$key2} = []
push @{ $data->{$key1}{$key2} }, @stuff;

I wanted this (in the future):

# Assuming $data->{$key1}{$key2} = []
push $data->{$key1}{$key2}, @stuff;

I've finished a draft implementation that works for push, pop, shift, unshift and splice. All existing Perl tests pass, as do new tests I've written that explore this new functionality. It will even auto-vivify as needed:

my $foo;
push $foo, @stuff; # $foo is now an arrayref

I'm still working on keys, values and each and those look much harder, but I hope to have something to share by next week.

Hacking the Perl core for smarter push and pop

nobody@example.com (dagolden) — 2010-09-08T21:33:24Z

In a recent post, I said I wished that Perl's built in functions for array containers would work directly on references.

Rather than this (today):

# Assuming $data->{$key1}{$key2} = []
push @{ $data->{$key1}{$key2} }, @stuff;

I wanted this (in the future):

# Assuming $data->{$key1}{$key2} = []
push $data->{$key1}{$key2}, @stuff;

my $foo;
push $foo, @stuff; # $foo is now an arrayref

I'm still working on keys, values and each and those look much harder, but I hope to have something to share by next week.

use Perl; Shutting Down Indefinitely

nobody@example.com (pudge) — 2010-09-08T20:51:00Z

As I am leaving my current job at Geeknet -- which has generously hosted use Perl; for all these years, since the site began in 2000 -- I am temporarily shutting down use Perl; tomorrow, Thursday, Sept. 8. I plan to leave the site "static" for now, and then perhaps have it reappear elsewhere.

A Perldoc Pruning

nobody@example.com (chromatic) — 2010-09-08T16:34:33Z

I use perldoc all the time (the command-line version). I don't know how to be a productive Perl programmer without perldoc -f or perldoc Module::Name. Nor would I try.

One of Perl 5's selling points is that includes copious documentation of the core language and common tasks. If you've skim perldoc perltoc once in a while, you'll find documentation you really ought to read as well as documentation you will wish you had read previously.

Then you'll come across something like perlobj which, bless its little heart, really isn't that helpful anymore. It gives far too many implementation details along with helpful-sounding but ultimately unpleasant advice. (Explaining how to use indirect method invocation before warning not to use it in the final paragraph of the section? A lengthy discussion of garbage collection? A comaprison of Perl 5's default OO with C++? Code examples which show how to bypass method dispatch altogether as a didactic technique on how method dispatch works?)

That's not the worst file in the documentation.

Writing documentation is difficult. Writing good documentation is very difficult. Editing existing documentation is thankless and fragile and prone to arguments: someone invested hours in writing that documentation a decade ago. We should celebrate that work and offer our most sincere gratitude to everyone who's helped create the voluminous Perl documentation. Even so, when documentation has grown a layer of mold (or when our understanding of the best way to do things has changed), we need to do users the favor of giving them the best advice we have.

Sadly, we'll never see Programming Perl 4E, but we can work to improve the core documentation in terms of advice, accuracy, organization, and completeness. (Even a prominent link to the TPF Perl 5 wiki for "Object Best Practices" in the documentation could keep it relevant in seven years when so-called enterprise distributions begin to ship a Modern Perl, but that's a far different need.)

CPAN Release Perl::Critic::logicLAB 0.01 and policies

nobody@example.com (jonasbn) — 2010-09-08T14:05:35Z

After a long time I finally got my own Perl::Critic policies released and uploaded to CPAN.

I have created a Task implementation bundle listing my two own policies for now (I expect to add other policies used later on). This gives you the opportunity to download the policies by themselves if they look like something you would like to use or you can even bundle them yourself with other policies you make use of.

This packaging is an experiment and is not the recommended way and so it might change in the future, so let me know if you have any feedback on the packaging, both if you are using Perl::Critic::logicLAB or the actual policies directly.

The policies which have also just been released and currently listed in Perl::Critic::logicLAB are:

Both are simple policies, but hopefully useful.

All should be available on CPAN by now.

jonasbn, Copenhagen

An Unexpected Test Result

nobody@example.com (Ovid) — 2010-09-08T13:27:27Z

I spent several hours debugging a catastrophic test suite failure today. As our test classes take over an hour to run and the failure takes place near the end of the test run, it was a very annoying issue to debug. Unfortunately, the test class in question passed when run by itself, but not when run in the entire suite. That usually means the global state had been altered in an unexpected way, and boy had it! Seems the test was failing because it was trying to run a method that a completely separate test class had -- and those classes weren't related by inheritance. It was very confusing until I finally realized that someone had mistyped a package name at the top of the test class. A few minutes later I had a new test which verified the package name ... and found ten other misspelled package names (out of 325 packages).

You'll need to adjust this to taste (and it assumes that the first thing which looks like package declaration is the package declaration).

#!/usr/bin/env perl

use Test::Most 'bail';
use File::Find;

sub expected_package_name($) {
  my $file = shift;
  $file =~ s{^t/lib/}{};
  $file =~ s{\.pm$}{};
  $file =~ s/\//::/g;
  return $file;
}

sub found_package_name($) {
  my $file = shift;

  # we assume first package name found is actual
  open my $fh, '<', $file or die "Could not open $file for reading: $!";
  my $package;
  while ( my $line = <$fh> ) {
    next unless $line =~ /^\s*package\s+((?:\w+)(::\w+)*)/;
    return $1;
  }
}

my @files;
find(
  { no_chdir => 1,
    wanted   => sub {
      my $file = $File::Find::name;
      return if !-f $file || $file !~ /\.pm$/ || $file =~ /\.svn/;
      push @files =>
        [ $file, found_package_name $file, expected_package_name $file];
    },
  },
  't/lib/Tests'
);
plan tests => scalar @files;
for my $file (@files) {
  my ( $file, $have, $want ) = @$file;
  is $have, $want, "Package name correct for $file";
}

An Unexpected Test Result

nobody@example.com (Ovid) — 2010-09-08T13:18:01Z

You'll need to adjust this to taste (and it assumes that the first thing which looks like package declaration is the package declaration).

  #!/usr/bin/env perl

use Test::Most 'bail';
use File::Find;

sub expected_package_name($) {
  my $file = shift;
  $file =~ s{^t/lib/}{};
  $file =~ s{\.pm$}{};
  $file =~ s/\//::/g;
  return $file;
}

sub found_package_name($) {
  my $file = shift;

  # we assume first package name found is actual
  open my $fh, '<', $file or die "Could not open $file for reading: $!";
  my $package;
  while ( my $line = <$fh> ) {
    next unless $line =~ /^\s*package\s+((?:\w+)(::\w+)*)/;
    return $1;
  }
}

my @files;
find(
  { no_chdir => 1,
    wanted   => sub {
      my $file = $File::Find::name;
      return if !-f $file || $file !~ /\.pm$/ || $file =~ /\.svn/;
      push @files =>
        [ $file, found_package_name $file, expected_package_name $file];
    },
  },
  't/lib/Tests'
);
plan tests => scalar @files;
for my $file (@files) {
  my ( $file, $have, $want ) = @$file;
  is $have, $want, "Package name correct for $file";
}

Actual Perl Marketing

nobody@example.com (nobody) — 2010-09-08T11:04:22Z

Here are two examples for how the Amelia Perl logo can be used in actual marketing material. :)

The first one is a book cover for the free Perl 6 book included in the Rakudo Star distribution. (download)

The second is a quick'n dirty (i had one hour) cover for a Mojolicious flyer Marcus Ramberg will be handing out at JavaZone 2010.

P.S.: I'm looking for fun T-Shirt design ideas, leave a comment if you have one!

Permalink | Leave a comment »

How can I troubleshoot my Perl CGI script?

nobody@example.com (brian d foy) — 2010-09-08T04:06:59Z

Awhile ago I moved my How can I troubleshoot my Perl CGI script? to StackOverflow. I'm just getting around to telling everyone about it because it was pretty far down on my to do list.

I think this has almost pushed the old location on SourceForge out of the googlebrain, but it wouldn't hurt for people to link to it in a blog post, tweet, whatever to encourage Google to find this one. Someday SourceForge will disappear and we won't have to worry about it anymore. How is it even still alive? StackOverflow has pretty good googlejuice though, maybe because Google likes StackOverflow.

Since it's on StackOverflow, this also means that I'm basically letting go of it. StackOverflow encourages people to revise the questions and answers of other to improve them, and I've given it wiki status to encourage that even more. Take a look, see what I've left out (or left in), what's new and exciting (or old and boring).

Even if you don't (or can't) edit it just yet, I'd appreciate any comments on how to bring it up to date. Maybe another StackOverflow user can make the changes if I'm too busy.

Also, sadly, the only thing keeping the bad Perl info out of StackOverflow is a small band of knowledgeable Perlers patrolling the answers (Sinan used my summer absences to pass me as the highest rated Perl user there). If you're looking for a way promote Perl in a useful way (and you actually know Perl), consider helping out. Providing good answers, voting on good answers (and against bad answers), and refining other answers helps the entire world.

How can I troubleshoot my Perl CGI script?

nobody@example.com (brian d foy) — 2010-09-07T20:41:31Z

Awhile ago I moved my How can I troubleshoot my Perl CGI script? to StackOverflow. I'm just getting around to telling everyone about it because it was pretty far down on my to do list.

Even if you don't (or can't) edit it just yet, I'd appreciate any comments on how to bring it up to date. Maybe another StackOverflow user can make the changes if I'm too busy.

The End of CPAN Testers 1.0

nobody@example.com (Robert) — 2010-09-07T16:49:30Z

Thsi is reposted from the CPAN Testers blog:

The End of CPAN Testers 1.0

By CPAN Testers on September 6, 2010 1:28 PM

As of this weekend, the final switch to turn off the SMTP gateway for CPAN Testers was flipped. You can no longer post anything to the old cpan-testers mailing list, and any attempts now will result in a bounce message.

Our thanks to Robert and Ask over at the Perl NOC for looking after us all these years, and for being very patient with us while we got the HTTP gateway up and running over the last 9 months.

As a consequence, anyone wishing to still be a part of the CPAN Testers community, now needs to upgrade their test environments, to use the latest smokers and associated libraries. In the main this will involve a simple upgrade of your smoker client and the installation of 4 specific modules (which in turn will install any additional prerequisites needed). You will then need to acquire a metabase profile. For full details of the steps necessary please see the Quick Start page on the CPAN Testers Wiki.

For those casual testers, the upgrade will initially involve some manual intervention, although we hope to automate this as soon as we can. If you do have any problems, or are confused by any of the instructions, please post to the cpan-testers-discuss mailing list, where the developers and other experienced testers can help you.

The end of an era.

The End of CPAN Testers 1.0

nobody@example.com (Robert) — 2010-09-07T16:49:30Z

Thsi is reposted from the CPAN Testers blog:

The End of CPAN Testers 1.0

By CPAN Testers on September 6, 2010 1:28 PM

Our thanks to Robert and Ask over at the Perl NOC for looking after us all these years, and for being very patient with us while we got the HTTP gateway up and running over the last 9 months.

The end of an era.

CPAN Testers Summary - August 2010 - Mourning Sun

nobody@example.com (CPAN Testers) — 2010-09-07T12:39:18Z

It's the end of an era. After 11 years from the first official CPAN Testers test report submission, the cpan-testers mailing list has finally closed its doors. From now on, anyone sending a test report via SMTP, will receive a bounce-back email. Most have already upgraded and reconfigured their smoker clients to use HTTP/S. For those that haven't or are new testers wanting to start afresh, please read the Quick Start page on the CPAN Testers Wiki, and join the cpan-testers-discuss mailing list to ask for help and advice.

For those wondering still wondering why we have moved from SMTP to HTTP submissions, please see my talk from YAPC::Europe, entitled "CPAN Testers 2.0 - I love it when a plan comes together". It was a talk I tried to give some background to for our reasons and motivations for the move. However, the bottom line is that we want CPAN Testers to evolve and grow further, with more diagnostics and analysis. With the old method of reporting and submission, that just wasn't possible. We have lots of ideas to expand the reporting, but first we need CT2.0 to settle in. We need to make upgrading and installation for anyone, especially our casual testers as easy as possible. There is still some fine tuning happening, but we are moving forward.

While at YAPC::Europe this year in Pisa, the White Camel Awards were announced. Despite being a reluctant recipient, I was awarded one for my work here with CPAN Testers. While I might be the glue that keeps us together, it really is all of the CPAN Testers Community that makes it all worthwhile. Though I saw the value and worth of what we do several years ago, and perhaps have had more time and motivation to promote what we do, the award really is a big big thank you to all the testers and developers who have been a part of CPAN Testers for the past 11 years. It has been a pleasure meeting many of you at conferences and workshops over the years, and hopefully I'll get to meet many more in the future. I started my involvement in CPAN Testers because of a BOF Léon Brocard gave at YAPC::Europe 2003 in Paris. In turn over the past few years I've helped to encourage others to become involved. The CPAN Testers Community has continually evolved and become a very respected community based testing team, even outside of the echo-chamber. I look forward to what we can achieve in the next 11 years.

In the final days of the SMTP submissions, I have been back mapping many of the addresses to people. Last month I also sent out the request email, for testers to help identify themselves. I had a great response, to which I thank you all, and managed to update several entries. In addition, several newer testers have followed my request and used their CPAN/PAUSE email, or have identified themselves well enough for me to spot them. In addition I took some time to work though mailing lists, whois entries, HTML source, open source code and all manner of nooks and crannies around the internet to identify many more. In all, over the last 2 months I've mapped 167 addresses to real people, of which 106 are new mappings to testers never previously identified. Many of these are brand new testers.

Because the new system of registering a profile is slightly different, the new mechanism to map testers is now also being fed from the Metabase. As such the new Administration system, that has been waiting in the wings for over a year, needs a few updates to be able to use both the new and old systems together. This shouldn't be a huge amount of change, but it does mean that it will be a little while longer before we can launch it.

One final achievement that needs noting from last month is the fact that we passed the 8 millionth accepted report submission. 11 years ago, I wonder if those first testers ever thought that we would have amassed so many reports. We were getting through roughly 1 million reports every 5-6 months back last year, but the throttling and switch over have reduced the submissions for the first half of this year. We're starting to see the numbers climb again, so I expect this time next year we should have passed the 10 millionth report submission.

Onwards and Upwards....

Cross-posted from The CPAN Testers Blog

Awesome Perl projects PT. 1

nobody@example.com (Sawyer X) — 2010-09-07T08:24:16Z

I hope to showcase and talk about a great Perl project every once in a while. Hope this lasts beyond one post. :)

We recently added emailing capabilities to an in-house application. Unfortunately sending the emails adds roughly 1 minute to the runtime. I decided to take a gander at swaks and see how it's being done there.

Swaks (SMTP transaction tester) is a great application for all systems administrators. It takes the pain away from testing email setups. Instead of echo msg | mailx -n -t ... and thinking of whether it's heirloom mailx, mail, nail or which version of mail it is, or whether you're using sendmail or exim or qmail or postfix (and in comes the headache...) - you can just write swaks -t addr -f addr. You don't even need the from field, but it's just as easy to add.

Swaks saves you the trouble of tailing logs and instead just shows you everything that's going on in the transport. It's easy to work with and it supports a lot of other options: it works with piping, unix sockets, input/output files, attachments, TLS, authentication, supports 12 mail protocols (from SMTP to LMTPSA), can work as a server(!) and much more!

Swaks is truly one of the most awesome Perl projects in any sysadmin book. Let's look at the core.

The good parts:

It uses strict!

It's divides to subroutines (that make sense).

The code is documented.

The application is documented (in POD!).

Clear code, skimmable.

Relatively concise, compared to the amount of stuff it can do.

Well thought-out as an application.

I could not find a single bad thing about this program, only not-so-good stuff.

The not-so-good parts:

Old indirect style of creating objects.

No warnings.

I wish more modules would be used to remove a lot of the code handling cmd opts.

(today using App::FatPacker this is no longer much of a problem)

Overall: This is an excellent project and something of which Perl should be proud, IMHO.

Awesome Perl projects PT. 1

nobody@example.com (Sawyer X) — 2010-09-07T06:58:57Z

I hope to showcase and talk about a great Perl project every once in a while. Hope this lasts beyond one post. :)

Swaks is truly one of the most awesome Perl projects in any sysadmin book. Let's look at the core.

The good parts:

It uses strict!

It's divides to subroutines (that make sense).

The code is documented.

The application is documented (in POD!).

Clear code, skimmable.

Relatively concise, compared to the amount of stuff it can do.

Well thought-out as an application.

I could not find a single bad thing about this program, only not-so-good stuff.

The not-so-good parts:

Old indirect style of creating objects.

No warnings.

I wish more modules would be used to remove a lot of the code handling cmd opts.

(today using App::FatPacker this is no longer much of a problem)

Overall: This is an excellent project and something of which Perl should be proud, IMHO.

An index for The Perl Journal articles

nobody@example.com (brian d foy) — 2010-09-07T02:37:37Z

A couple of years ago I put together a list of The Perl Journal articles I could find on the Dr. Dobbs website. They changed some of their URLs, so I updated those to avoid all of the redirects and in the process found several more articles. My TPJ index is on Perlmonks. You can see some of the beginnings of popular projects, such as Moose, in some of the articles.

An index for The Perl Journal articles

nobody@example.com (brian d foy) — 2010-09-07T02:35:03Z

Essential Philosophy for Perl 5 Novices

nobody@example.com (chromatic) — 2010-09-06T19:49:54Z

If you're in the Portland, Oregon area, come to the Portland Perl Mongers September 2010 Meeting on Wednesday, September 8.

Not only will Schwern talk about Test::Builder 2 (Test::Builder is the foundation of the Perl Testing Revolution), but I'll talk about what novices must understand about Perl 5 before they can become adepts.

We're experimenting this month with a combination of novice-friendly primers and deeper subjects. We'd love to attract more people interested in Perl but not necessarily experts as well as people who've never written much Perl at all. Tell your friends.

... and for a preview of my talk, I'll explain:

The two types of context in Perl 5
What context really means, and why you already understand it
What implicit variables really mean and why you already understand them
What concision means and why it's not as scary as you think
How to chunk Perl expressions into parts you already understand
How to navigate the Perl 5 documentation

If you can't make the meeting, I'm sure a podcast will eventually appear. You could also read the draft of Modern Perl chapter 1 for an overview.

The End of CPAN Testers 1.0

nobody@example.com (CPAN Testers) — 2010-09-06T12:29:10Z

Our thanks to Robert and Ask over at the Perl NOC for looking after us all these years, and for being very patient with us while we got the HTTP gateway up and running over the last 9 months.

The end of an era.

The Pugs repository is dead; long live Mu! (2010.09.06 2:30)

nobody@example.com (masak) — 2010-09-06T06:30:29Z

This weekend marks the end of a quite astonishing era. The Pugs repo, that hosted all the amazing Perl 6 activity, is no more. At its height, this repository had 242 committers! I just checked.The Pugs repository has functioned as a common writing area for Perl 6-related things. First Pugs; then a lot of external modules and scripts written in Perl 6; what would eventually morph into the Perl 6 test suite; even the Perl 6 specification and the standard grammar. Commit bits (write access credentials) were handed out liberally, and newcomers were encouraged to help improve things they found amiss. The degree to which this system worked without a hitch has been quite astonishing. There have been no edit wars, no vandalism, no banning. Just the continuing flow of commits. Trust the anarchy.So why are we killing off the Pugs repository? Well, technologies come and go; not so much because they worsen by each year, but because our expectations rise in a sort of software inflation. The SVN repository became too high-maintenance, and a transition to git was the natural next step. The Pugs repository has been split up into the git repositories linked to in the previous paragraph. Those bits that don't belong in any of the standard bins remain in the Mu repository. (Its name is a reference to the most-general object type in Perl 6, what in other languages is commonly known as 'Object'.)I for one salute our new git-based overlords! May the commits keep flowing even under this new system. Also, moritz++ for carrying out the move.

Disappearing CPAN Modules

nobody@example.com (Jared) — 2010-09-06T04:30:18Z

Somewhere in my Super Programming Languages post, I asserted that in some of my scripts, 95% of the work has already been done by third party libraries. Such is the power of the CPAN! And other folks obviously use Perl for similar reasons – there are libraries available that solve at least part of their problem.

So, I’m surprised when people complain that libraries have been provided that help them out.

Steve obviously had second thoughts over publishing this post (google cache). Is blogpost necrophilia reasonable here? I’m afraid I’ve seen other people make similar arguments, and I can’t remember the location of their posts. Sorry Steve.

Ok, so from that, I can gather this: I’m screwed because I used perl for a script, and now the module author has decided to completely abandon the module, because it is based upon another module that doesn’t install worth anything. Cool!

He used an extremely useful and mature scripting language and a module that solves part of his problem. Because the module doesn’t work with a later version of that excellent scripting language, he’s doomed, doomed, DOOMED I tell you. And of course, it’s Perl’s fault.

The first thing is that he’s not doomed. He is simply going to have to find an alternative module or implement the functionality provided by the module himself. He’d have had to do that if the module wasn’t provided anyway. So in no way was he disadvantaged by having the module (and Perl) available.

The other thing is that this happens in every changing environment. Say your C++ compiler upgrades and you were inadvertently depending on a particular bug. Oops! (Don’t laugh – it happens). If your firm upgrades Excel to version 2000007, maybe your macros aren’t going to run any more. We’re moving to a 64-bit OS and I’m glad there’s a bunch of Perl that I can be confident will more or less work. I’m not looking forward to porting the C++ though.

To try and add a fair and balanced viewpoint, I should point out that part of the argument does make sense. It is disappointing that Daemon::Simpler has gone from Backpan. Having said that, sometimes it is important to take some responsibility. Any module that I bring into our production environment is archived as is the current version of perl we’re using.

Filed under: Perl Tagged: portability

Should Module::Install move to explicit plugin declaration? (2010.09.05 22:26)

nobody@example.com (Alias) — 2010-09-06T02:26:06Z

Module::Install has been through a long period of gradual stability over the last year, without any really dramatic improvements to the grammar or APIs.

With the more urgent "it doesn't work with blah" stuff mostly solved now, one of the big remaining issues is around error clarity and excessive magic.

For example, some random author that is trying to checkout a Catalyst project needs:

1. To have Module::Install installed.
2. To have Module::Install::Catalyst installed.

In the case of the former, you get the semi-cryptic but at least standard "Can't find inc/Module/Install.pm in @INC" message, so the error is resolvable.

But in the latter case, you're likely to get something like "Unknown command 'catalyst_ignore'", with no real obvious resolution mechanism.

I think this idea of automatic plugin discovery is starting to hit it's limits in terms of clarity.

And so I'd like to do something counter to my natural instincts here, and make M:I more verbose.

I'm thinking of something like the following for explicitly declaring the use of a non-core Module::Install extension.

use inc::Module::Install qw{ Catalyst XSUtil };

This would both allow M:I to error with a much more meaningful error when you don't have a plugin, and also prevent the loading of unused plugins which should prevent accidental plugin collisions (some of which I've seen occurring in the CPAN Testers machines).

Thoughts?

Should Module::Install move to explicit plugin declaration?