I recently encountered a Cpan module which doesn't install from its distribution yet passes all its tests, and I was wondering whether the glitch is a generic one which should be addressed.
This particular module is not my concern (its maintainer responded speedily and is now looking at fixing it), but it illustrates the issue: http://cpansearch.perl.org/src/JZAWODNY/DBIx-DWIW-0.49/ Note the module source is in the tarball at ./DBIx/DWIW.pm, and that is reflected in Makefile.PL. Running make creates the ./blib/lib/DBIx/ directory but doesn't copy the module to it (nor generate the manpage). It appears to work fine with the source at either ./DWIW.pm or ./lib/DBIx/DWIW.pm (and a corresponding Makefile.PL). * Is this a known limitation of MakeMaker or a bug? If a bug then I'll report it. If a limitation, would it be possible for MakeMaker to detect this condition and bail out (on both make dist and make), rather than giving the impression it's succeeded? * make test succeeded because perl puts the current directory at the end of @INC. Because DBIx::DWIW isn't in ./blib/, the one at the top of the tarball is found and used for the tests. Obviously this doesn't happen with other tarball layouts because ./lib/ isn't in the path for make test (and ./DWIW.pm can't be in the path, because the parent directory isn't called DBIx; that would be an issue for single-level modules though). * That the module doesn't install at all makes a slight mockery of the many Cpan Testers reports giving it a PASS: http://www.cpantesters.org/show/DBIx-DWIW.html#DBIx-DWIW-0.49 Yes, I know why that is, but that doesn't make it any better. It was a sys-admin colleague with little Perl experience who encountered this problem, while trying to install a program which uses this module. That Perl has this QA thing which tells you which platforms a module will work on but that doesn't actually mean it'll install only adds to external perceptions of Perl being confusing and awkward. * Even if MakeMaker were modified so that this distribution would install, it's still concerning that modules with this distribution layout get picked up by make test: there are other sorts of mistakes a module author could make which would result in a bogus test pass because of this. * So it'd be nice if when running tests the current directory weren't in @INC. Putting the following line in the Test and Test::More modules would achieve this: BEGIN { pop @INC if $INC[-1] eq '.' } But that's so non-backwards-compatible that I'm guessing it would cause problems elsewhere. * An alternative would be to have make test do the above (for example by putting the above line in a module and having make test -M that module when running a test script). That limits the scope of the change, but it's still backwards-incompatible -- and it means anybody running an individual test directly still risks including a file they didn't intend to. * Or make test could cd into the blib/lib/ directory, such that the current directory is one that should be in the path. But Michael Schwern a few days ago argued that tests should be run from the parent directory: http://www.nntp.perl.org/group/perl.qa/2009/05/msg12215.html Any thoughts? Smylers
