All the Perl that's Practical to Extract and Report

perlbug for modules

brian_d_foy on 2003-12-04T20:09:15

The perl distribution comes with perlbug, a utility to report bugs about perl. It can collect various things the perl developers want to see to investigate the bug.

Now I am thinking that something like that should be available for module developers too. Of course, you can specify the email address and whatnot with perlbug, but that is too much work.

After five minutes of thought, here is what I want in this little tool:

  • Automatically discover who the mail should go to
  • Find the module dependencies and get the versions of those locally installed
  • Automatically capture the output when things blow up (because some users either do not include it or try to retype it)
  • Include the source of the program (same reason as above). This is a test case hopefully, but maybe not (maybe it could warn if the test file is over a certain size)
  • Include a user comment, like perlbug already does
  • Collect errors from `make all` (have to think about this one)
  • Submit to rt.cpan.org, perhaps
  • Have an info only mode---e.g. who is the author and what is his email address.
  • Warn if newer versions of some prereqs exist on CPAN (sometimes the problem is a dependency and updating those modules fix it---happened to me twice this week)
  • Grab command line arguments
  • Create a test file automatically, perhaps, based on the data it collects
  • Grab system data (uname -a, etc)
  • Point out places the module is discussed or where to find help


I think a lot of this should be really simple. I like the idea of developers putting pointers to discussion forums in the Makefile.PL (or Build.PL), where I think this utility should get most of its info, or maybe in the YAML file (which I do not know too much about just yet).

I also like the idea of running this program in place of perl so it can collect a lot of info. If the program runs like

perl my_script.pl argument argument


I want to run this program (let's call it bugger) like

bugger my_script.pl argument argument


and it forks (or something) to the real perl. Once it runs, it bundles all of the info together somehow and sends it off to the correct place.

If this thing existed, I think it could be a big feather in Perl's cap when all the suits start yammering about how open source is just a bunch of script kiddies, and so on.

So, comments are enabled. Give me some reasons that this is a really bad idea I should put out of my head. And, what other products have something like this?

perlbug isn't quite that sophisticated :)

hfb on 2003-12-04T21:11:59

and CPANPLUS has an interface to the testers, http://search.cpan.org/user/autrijus/CPANPLUS-0.047/lib/CPANPLUS/TesterGuide.pod, which autrijus added after I asked about it. I still point people to testers as the more tests for each platform and a wide variety of platforms would help an author more than just some random bug email from joe user no matter how detailed. Besides, making it easier for people to bitch about something in this community isn't always a smart move. And, let's not forget that people seem to filter their mail rather aggressively these days so suggesting that authors get more email might not go over very well either. If people can't be bothered to use the RT bug database to report a bug, they likely can't be bothered to write a whole email which won't get logged and tracked.

Testers, testers, testers. Some day, it might even catch on after people have tried to reinvent something more complicated enough times.

Re:perlbug isn't quite that sophisticated :)

brian_d_foy on 2003-12-05T01:24:25

Testers is only as good as the tests that the author writes. Users always seem to find an untested case though.

As for RT, I don't expect everyone to know how to use it, and even then, the reports I get in RT have very little information, which is why I want something to collect that info automatically.

Re:perlbug isn't quite that sophisticated :)

hfb on 2003-12-05T10:36:44

Well, I cant help the cases where the authors don't write tests for their modules. The interface does allow for comments and such from the users though. I don't see how what you want and what already exists is different save for the extra information collection which could be added into cpanplus and cpan.pm.

brian rules! :-)

ethan on 2003-12-05T08:39:52

I think this is a jolly good idea. The amount of additional mails module authors might get is nothing compared to the amount of time that could be saved by reports that are actually useful.

Most reports are incomplete. They usually don't contain the version of perl or the version of the modules they used, or a combination thereof. We seldom get the actual output users receive from the broken programs, nor even the code they used. Establishing these information often takes one or two additional emails to the chap reporting the bug.

Finally, it would allow formalizing the format of reports so that rules can be easily plugged into .procmailrc. More than once a report has been moved into my spam folder and I almost missed it (maybe I did even miss a few - how should I know?)

Some things on your list of possible features will be tricky to do, though. I don't see how a list of prerequesite modules could be created if the initial Makefile.PL no longer exists or is buried somewhere deep down in the root's home directory. If I understand you correctly, this perlmodbug tool should not just be used when installing a module but also when discovering a bug later while using it.

but the meta-data might not be there

htoug on 2003-12-05T12:07:48

Normally you won't be able to look at the Makefile.PL or the YAML files after instalation, so this would only be useful for reporting errors found during installation - which testers and CPANPLUS does quite nicely.

After installation all knowledge of the original package is long gone...

Re:but the meta-data might not be there

brian_d_foy on 2003-12-05T16:00:28

There might be other ways to do this even if the distribution is gone. Somewhere in the universe that information exist. The trick is to figure out how to get it. So it is not as simple as opening a file, but I figure there might be one or two smart people who don't give up so easily. :)

A lot of the other features do not depend on this, however, and, again, testers and CPANPLUS are only as good as the tests, which everyone should realize are never perfect.