Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The plan, when I first thought of it, sounded wonderful. I thought about installing all perls from 5.6.1 (5.6.0 would be a bit unfair) to 5.8.8 and blead on one box, and smoke testing new uploads to CPAN upon all (12, by my count) versions. And then the idea was to try smoking on threaded and non-threaded perls too. If a module got through all that, it would be Good. Too many test reports are from 5.8.7 these days.

    So I started out with most of 5.8 to see how things worked out. The idea was to have as vanilla installations as possible. The more modules not available in the local installation, the more likely it would be that it would catch an overlooked assumption about such-and-such a module being present.

    The first thing that went wrong is that CPANPLUS doesn't really expect you to share the config between a dozen different perls on one box. For a start, it downloads the same file over and over again, for each version...

    The next thing that went wrong is all the modules that use Module::Build (that don't provide a Makefile.PL) failed. So I had to install that, along with its prerequisites. And a couple of other modules were more or less manditory.

    Then there was the problem of modules that have prerequisites. And those modules themselves in turn have other prerequisites. By the time you come back to the top to build the module you set out to build in the first place, the @INC array doesn't contain the paths to the grandchild prerequisites, and so the test suites fail because they can't find modules that aren't even directly used.

    That problem doesn't show up in real builds, because those modules are really installed and are thus found in the regular @INC paths. Modules that use ExtUtils::AutoInstall seemed to be more affected.

    Not to mention all the modules that sit and hang waiting for a reply on STDIN for something or other. Why don't they know they're being run under a smoke environment and choose a sensible default?

    Finally, I tried upgrading to the latest version of CPAN::YACSmoke, but then it started reporting all tests as successes, regardless of the actual results. While this would no doubt make the authors happy, it wasn't really what I was after.

    I have burnt up enough tuits getting as far as I did; I can't really spend the time to go through the source and find out what's going wrong. Bug reports have been filed. In the meantime, I've given up smoking.

    Sorry about the fails. Release a new version, and I promise not to smoke it, at least not until the necessary modules go through a couple of point releases.
    • Sounds like a great plan. Smoking both threaded and non-threaded but otherwise identical is an excellent idea.

      For a start, it downloads the same file over and over again, for each version...

      Would CPAN::Mini help, getting everything once, and then you deploy from there into each?

      --
      Bill
      # I had a sig when sigs were cool
      use Sig;
      • Well... I actually wound up setting up a full local mirror, the initial rsync took about half an hour. But that's not the problem, that's just fixing the symptom without resolving the underlying cause. The backend should realise that if the tarball is sitting in the local author cache, it doesn't have to go out and fetch it again. It should not. Unless you delete the file or othtewise diddle with it so that the checksum no longer matches. I did spend a while trying to understand the code the provide a pat