[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl-qa
Subject:    Re: Cpan Dist Layout Issue
From:       Michael G Schwern <schwern () pobox ! com>
Date:       2009-05-24 1:35:38
Message-ID: 4A18A46A.3030101 () pobox ! com
[Download RAW message or body]

Executive Summary:  Not a bug.  The whole idea of putting .pm files outside
lib is wonky.  A warning from MakeMaker wouldn't hurt but I'm unconcerned with
the whole problem.


Smylers wrote:
> 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).

Looks like the author broke it in the 0.49 release.  Previously it was DWIW.pm.


> * 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?

Known limitation, though I had to scratch my head for a bit.  I'm not exactly
sure what the MakeMaker logic is here.  It probably thinks DBIx/ is a
sub-project, tried to find a Makefile.PL inside it, didn't find one and gave up.

I am unconcerned.  The whole idea of MakeMaker picking up files in the top
level source directory is wonky.  I'm glad Module::Build didn't inherit that one.

But fork and patch away to add a warning if you like.  Make sure it doesn't
fire on legit uses of .pm outside of lib/ (of which I have no idea what they
might be aside from t/lib/).
http://github.com/schwern/extutils-makemaker/tree/master


> * 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.

I'll bet that was the author's logic.


> * 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.

A pass also doesn't tell you if the tests are worth a damn, which they aren't
in this case.  I have no long term solution to this, and while there are
techniques to determine if a project's tests are any good they all require
detailed knowledge of the project.

Perhaps what we need is more social networking.  We've found this module, we
know its tests are crap, we should be able to disseminate this information to
users and the author.

You could try to test if the module got installed, but then figuring out
exactly what got installed is tricky.  Something as simple as "require
Foo::Bar" might be in order, but that assumes "Foo-Bar-1.23.tar.gz" installs
"Foo::Bar" which isn't always true.


> * 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.

Yes, very much so.  A lot of distributions rely on having "." in their @INC.
For example, there's the inc:: trick:

    use inc::Foo::Bar;

There's the t::lib trick:

    use t::lib::Foo::Bar;

All of these have simple work arounds, but I don't want to break shit for one
errant module.  And I think its handy.


> * Or make test could cd into the blib/lib/ directory, such that the
>   current directory is one that should be in the path.

AHHHHHHHH!!!!

Tests poop temp files all over the place.  The last place you want them is in
blib/lib where they might get picked up and installed.  If "make test" was
going to cd anywhere it would be into t/ but that ship has long since sailed.


  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

That's out of context here.  That was saying its overkill to beef up your
tests so they can be run from different directories.


-- 
184. When operating a military vehicle I may *not* attempt something
     "I saw in a cartoon".
    -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
           http://skippyslist.com/list/
[prev in list] [next in list] [prev in thread] [next in thread]