All the Perl that's Practical to Extract and Report

ActiveState testing

barbie on 2004-04-19T14:55:33

Spotted this link by accident over the weekend:

http://ppm.activestate.com
It contains all the test results when ActiveState have attempted to create PPMs for their repository. Discovered a few of mine need some updates. Ooops!

Thanks Activestate!

drhyde on 2004-04-19T15:15:27

For reporting the fscking bugs when you find them. Not. I never even knew that their custom version of the CPAN testers existed.

Re:Thanks Activestate!

barbie on 2004-04-19T15:39:28

Me neither. It would be nice, with the number of different setups they have, for them to use Test::Reporter somehow. If I can get it to work on Win32, I'm sure they'd find it a doddle.

Re:Thanks Activestate!

runrig on 2004-04-19T20:06:00

...For reporting the fscking bugs when you find them.

What I heard was that it was on the todo list, but the process is far from perfect, so they're not ready to turn that particular feature loose yet.

Re:Thanks Activestate!

barbie on 2004-04-19T23:13:49

I hope the change their minds. I shall be checking those pages a little more for my modules at least. It might improve the ActiveState PPM repository if they did send reports out, as there have been a few modules I was surprised to find unavailable. Now I know why.

Hmm....

davorg on 2004-04-19T17:16:18

Seems to be some pretty weird stuff going on there.

For example, this problem (warning - very large page) seems to be caused by their program not being able to configure CPAN.pm correctly. And this one seems to imply that they aren't automatically installing pre-requisites.

Re:Hmm....

barbie on 2004-04-19T23:09:33

Module::Build is a law unto itself anyway. It can't be installed without manual installation. I have yet to have a successful cpan smoke test of Module::Build.

CPANPLUS has been having difficulties installing prerequisites for the past few months, so I wouldn't blame ActiveState too much for having odd reports either.

Re:Hmm....

jand on 2004-04-20T23:40:18

Makefile.PL has no business running CPAN.pm automatically, especially not when STDIN is not a tty. You would be surprised to see how many broken Makefile.PL scripts assume they are being run interactively. I wish module authors would instead provide complete PREREQ_PM listings.

Re:Hmm....

barbie on 2004-04-21T12:02:36

While in most cases I'd agree, there are some modules where an interactive session does aid installation. However, most of those that do interactive sessions properly, account for default values so a return will do the right thing.

It's the installations that cycle round in endless circles, when the right value hasn't been entered that gets me. There is a HTTP module that sits in a while loop until it gets the right entry. If you don't get the right entry after the second time (the first blank may be accidental), die with an appropriate error message or even better set up reasonable defaults. The HTTP module in question cause my automated smoke testing to run for 2 days (over a weekend) because of that.

While having a complete PREREQ_PM is good, it's not always possible or appropriate to include everything. Some features might not be required or may even be inappropriate for the user. You shouldn't have to install everything (including the kitchen sink) if you're never going to use certain features.