develooper Front page | perl.qa | Postings from June 2015

Re: Why does File::Path not respond to 'cover'?

Thread Previous | Thread Next
From:
Paul Johnson
Date:
June 28, 2015 15:44
Subject:
Re: Why does File::Path not respond to 'cover'?
Message ID:
20150628154356.GB22905@pjcj.net
On Sun, Jun 28, 2015 at 09:18:57AM -0400, James E Keenan wrote:
> On 06/27/2015 01:55 PM, yary wrote:
> >I believe that Devel::Cover excludes core modules, so that "your code"
> >isn't influenced by modules that are included (perhaps indirectly). Seek
> >out a switch/hash/regexp/sub to modify that behavior, there is one
> >somewhere!

I'm not convinced this is the problem because the file is actually being
reported on, it's just that the report says the coverage is 0.

Devel::Cover doesn't ignore core modules in the sense that it knows
which modules are core and alters behaviour for them.  But it does have
ways of ignoring modules either based on their names or their locations.
By default all of the modules in all of the directories of a pristine
@INC are ignored.  This effectively ignores core modules and all other
installed modules which, usually, is what you want.  Ignore here means
not to collect coverage data.  The code is obviously still run.

If Devel::Cover has got things wrong then this can all be altered with
command-line options, you shouldn't have to go grovelling around the
code.

However, in this case, the modules have not been installed and so they
won't be in that location and, by default, will not be ignored.  This is
why the coverage is reported, albeit as 0.

> >On Fri, Jun 26, 2015 at 10:08 PM, James E Keenan <jkeen@verizon.net> wrote:
> >
> >>Richard Elberger and I recently received co-maintenance bits on the
> >>File-Path distribution.  As is my wont, I ran it through Devel::Cover --
> >>but was surprised to see that 'cover' reported zero coverage.
> >>
> >>Does anyone know why File-Path is unresponsive to 'cover'?

I think the problem here is that Devel::Cover cannot provide coverage
for modules it uses itself.  For this reason I try to keep Devel::Cover
dependencies to a minimum.  File::Path, however, is one of the
dependencies.  This is described in to docs:
https://github.com/pjcj/Devel--Cover/blob/master/lib/Devel/Cover.pm#L1611

This means, I'm afraid, that there is no easy solution to getting
Devel::Cover to run with File::Path.

> Thanks, yary.  Yes, after I posted I recalled that Devel::Cover does
> exclude core modules.  IIRC, pjcj had a project called 'p5cover'
> which was intended to rectify that, but I don't know that project's
> current status.

Languishing, I'm afraid.  But even if it were working it could not
provide useful data for File::Path for the reason mentioned above.

> In any case, on my previous laptop I located some correspondence
> with pjcj from two years ago in which I reported having found a hack
> for this case:  Create a branch.  In the branch rename 'Path.pm' to
> something like 'ABCPath.pm', then do a global search-and-replace in
> all files (except things like README, TODO and Changes) to impose
> the new name. At that point you can run 'perl Makefile.PL && make',
> and from that point Devel::Cover sees a brand new library and
> calculates coverage.

Yes.  This works because the module is then separate from the standard
File::Path.  I suppose a solution could be to bundle File::Path with
Devel::Cover but under a different name.  Or perhaps take the parts of
File::Path which Devel::Cover uses and "inline" them somehow.  The same
argument could be used for the other modules Devel::Cover uses itself.
I am not enamoured of these options but they might bear thought.

Devel:Cover is also unable to provide coverage for itself, for the same
reason.  I have worked around that partially within Devel::Cover by
providing a reduced coverage option which uses the older method of
replacing the runops loop rather then replacing function pointers for
ops, and doesn't suffer from the same deficiency.

There is a small chance that you might get coverage for File::Path by
setting DEVEL_COVER_OPTIONS=-replace_ops,0 but I have not tried it and
wouldn't like to bet on it.  But if it doesn't work and anyone would
like to dig into it, that is where I would start.

-- 
Paul Johnson - paul@pjcj.net
http://www.pjcj.net

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About