All the Perl that's Practical to Extract and Report
use Perl Log In
brian_d_foy (44)
Journal of brian_d_foy (44)
perlbug for modules
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?
--Larry Wall in stab.c from the perl source code
perlbug isn't quite that sophisticated :) (Score:3, Interesting)
and CPANPLUS has an interface to the testers, http://search.cpan.org/~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.
Reply to This
Re:perlbug isn't quite that sophisticated :) (Score:2)
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 :) (Score:2)
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! :-) (Score:1)
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
but the meta-data might not be there (Score:2)
After installation all knowledge of the original package is long gone...
Re:but the meta-data might not be there (Score:2)
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.