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.
What are these indirect dependencies of which you speak?
Re:Huh?
ajt on 2008-07-10T11:59:48
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 working correctly with changes in the latest version of Sub::Uplevel on the testers machine. Test::Warn was listed in my module but Sub::Uplevel wasn't so only Test::Warn appeared in the Test statistics.
Re:Huh?
clscott on 2008-07-10T14:34:59
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?
Re:Huh?
ajt on 2008-07-11T11:59:22
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 the best practices and have improved their test coverage, even the best have problems that don't get detected in their test suite.
Re:Huh?
chorny on 2008-10-31T10:03:58
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.
