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 ]

ajt (2546)

  (email not shown publicly)

UK based. Perl, XML/HTTP, SAP, Debian hacker.

  • PerlMonks: ajt []
  • Local LUG: AdamTrickett []
  • Debian Administration: ajt []
  • LinkedIn: drajt []

Journal of ajt (2546)

Wednesday July 09, 2008
04:16 PM

Indirect Dependencies in META.yml?

[ #36881 ]

Recently tests for XML::RSS::Tools failed because one of the test modules did not play well with another module it required for the test, neither are part of my module.

During the debugging phase one the kind testers suggested adding indirect dependencies as well as direct dependencies to my META.yml/Build.PM/Makefile.PL files. Now that DrHyde has the CPAN dependencies service up and running it's actually easy to do this. It creates more work for the module maintainer but in theory it helps the testers to figure out what is going wrong at times, because of the apparently better statistics the test tools generate as a result of the extended dependencies.

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.
  • What are these indirect dependencies of which you speak?

    • Your module requires Foo, so you add Foo as a dependency, this is normal stuff. Foo requires Bar and Baz, which your module does not directly depend on. The suggestion therefore is to add Bar and Baz to your module's list of dependencies in it's META.yml file for example. That way when the automated CPAN tests are run, the version of Bar and Baz will be reported as well as Foo.

      In my case XML::RSS:Tools uses Test::Warn in some tests. Test::Warn uses Sub::Uplevel. The problem was that Test::Warn was not worki

      -- "It's not magic, it's work..."
      • Why does your distribution have to make up for someone else's broken distribution?

        Is there not already a test for PAUSE or CPANTS to test that a distribution is "broken" because it doesn't specify its dependencies?

        • In theory that is the case. However in my case the two modules both passed all their tests and so were installed, it is only when used in a specific way in my tests that they failed. This shows up as a test failure in my module and nothing in the modules with a problem. The CPAN tester's report only details modules that are direct named dependencies, so it's hard to replicate the test scenario and hence debug it.

          While the quality of many modules on CPAN has improved and many people have striven to use only

          -- "It's not magic, it's work..."
        • It is not broken. Test::Warn depends on Sub::Uplevel. Test::Warn 0.10 dies with new version of Sub::Uplevel (when it was upgraded after install of Test::Warn). It is not possible to modify old versions of Test::Warn to require old Sub::Uplevel. New version of Test::Warn works with both old and new version of Sub::Uplevel.

          I already thought about this situation. There is a field in META.yml to specify conflicts, but none supports it.