Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Thursday December 04, 2003
03:09 PM

perlbug for modules

[ #16171 ]

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, 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 argument argument

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

bugger 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?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • and CPANPLUS has an interface to the testers,, 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.

    • 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.
      • 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

  • 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
  • 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...

    • 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.